Re: [openstack-dev] [keytone] Pike PTL
Steve, You've done amazing job. Thanks for that and making keystone even better! 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
[openstack-dev] [keystone] Stepping down from keystone core
Hi, Due to my current responsibilities I cannot serve as keystone core anymore. I also feel I should make some space for others who will surely bring new quality to the OpenStack Identity Program. It's been a great journey, I surely learned a lot and improved both my technical and soft skills. I can only hope my contributions and reviews have been useful and made OpenStack a little bit better. I wish you all the best in the future. With kind regards, 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] changes to keystone-core!
++! On 01.02.2016 01:26, Lance Bragstad wrote: ++ I'm happy to see this go through! Samuel and Dave have been helping me out a lot lately. Both make great additions to the team! On Thu, Jan 28, 2016 at 9:12 AM, Brad Topol <bto...@us.ibm.com <mailto:bto...@us.ibm.com>> wrote: CONGRATULATIONS Dave and Samuel. Very well deserved!!! --Brad Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 <tel:%28919%29%20543-0646> Internet: bto...@us.ibm.com <mailto:bto...@us.ibm.com> Assistant: Kendra Witherspoon (919) 254-0680 <tel:%28919%29%20254-0680> Inactive hide details for "Steve Martinelli" ---01/27/2016 05:17:12 PM---Hello everyone! We've been talking about this for a lo"Steve Martinelli" ---01/27/2016 05:17:12 PM---Hello everyone! We've been talking about this for a long while, and I am very pleased to From: "Steve Martinelli" <steve...@ca.ibm.com <mailto:steve...@ca.ibm.com>> To: openstack-dev <openstack-dev@lists.openstack.org <mailto:openstack-dev@lists.openstack.org>> Date: 01/27/2016 05:17 PM Subject: [openstack-dev] [keystone] changes to keystone-core! Hello everyone! We've been talking about this for a long while, and I am very pleased to announce that at the midcycle we have made changes to keystone-core. The project has grown and our review queue grows ever longer. Effective immediately, we'd like to welcome the following new Guardians of the Gate to keystone-core: + Dave Chen (davechen) + Samuel de Medeiros Queiroz (samueldmq) Happy code reviewing! Steve Martinelli OpenStack Keystone Project Team Lead__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe <http://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://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 -- Marek Denis [marek.de...@cern.ch] __ 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] [Horizon] Federated Login
Hi On 05.08.2015 19:36, Dolph Mathews wrote: yes this was my understanding of the discussion that took place many months ago. I had assumed (wrongly) that something had been done about it, but I guess from your message that we are no further forward on this Actually 2) above might be better reworded as - a new policy/engine that allows public access to be a bona fide policy rule The existing policy simply seems wrong. Why protect the list of IdPs? Would Rackspace be happy to expose list of their customers to everybody? -- cheers Marek __ 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] Liberty SFE Request - Dynamic Policies
I am +1 on this SFE. Dynamic Policy team has been working hard on this and they will for sure deliver nice features for Liberty. -- Marek Denis [marek.de...@cern.ch] __ 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][FFE] ECP wrapped assertions
Hi, I strongly support this request. On 23.03.2015 22:42, Steve Martinelli wrote: I'd like to request an exemption for the following to go into the Kilo release. This work is crucial for: - Keystone to Keystone communication. An ECP wrapped SAML assertion will make it much easier for consumers and clients to use the K2K feature in Keystone. Currently, a client must take the generated SAML response and must prepare the ECP envelope themselves. This should be handled by Keystone, and not the clients. The client should be able to ask for the ECP wrapped assertion and hand it off to another Keystone. Why this needs an FFE? - To properly created an ECP wrapped a SAML assertion, a relay state property must be known, (as it's used to compute a value in an ECP specific field). This depends on how the service provider has their mod_shib configured. We will need to add a new property to the keystone resource 'service provider' - the spec change is here: https://review.openstack.org/#/c/166086/ Status of the work: - The patches necessary for this feature already and split into two patches. 1) To add a new relay_state_prefix property to the service provider resource: https://review.openstack.org/#/c/166078/and 2) to actually use this new property in order to generate the ECP assertion: https://review.openstack.org/#/c/162866/ Thanks, Steve Martinelli OpenStack Keystone Core Marek Denis OpenStack Keystone Core __ 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][FFE] - IdP ID (remote_id) registration and validation
Hello,
One very important feature that we have been working on in the Kilo
development cycle is management of remote_id attributes tied to Identity
Providers in keystone.
This work is crucial for:
- Secure OpenStack identity federation configuration. User is required
to specify what Identity Provider (IdP) issues an assertion as well as
what protocol (s)he wishes to use (typically it would be SAML2 or OpenId
Connect). Based on that knowledge (arbitrarily specified by a user),
keystone fetches mapping rules configured for {IdP, protocol} pair and
applies it on the assertion. As an effect a set of groups is returned,
and by membership of those dynamically assigned groups (and later
roles), an ephemeral user is being granted access to certain OpenStack
resources. Without remote_id attributes, a user, can arbitrarily choose
pair {Identity Provider, protocol} without respect of issuing Identity
Provider. This may lead to a situation where Identity Provider X issues
an assertion, but user chooses mapping ruleset dedicated for Identity
Provider Y, effectively being granted improper groups (roles). As part
of various federation protocols, every Identity Provider issues an
identifier allowing trusting peers (Keystone servers in this case) to
reliably identify issuer of the assertion. That said, remote_id
attributes allow cloud administrators to match assertions with Identity
Providers objects configured in keystone (i.e. situation depicted above
would not happen, as keystone object Identity Provider Y would accept
assertions issued by Identity Provider Y only).
- WebSSO implementation - a highly requested feature that allows to use
federation in OpenStack via web browsers, especially Horizon. Without
remote_ids server (keystone) is not able to distinguish what maping rule
set should be used for transforming assertion into set of local
attributes (groups, users etc).
Status of the work:
So far we have implemented and merged feature where each Identity
Provider object can have one remote_id specified. However, there have
been few request for stakeholders for ability to configure multiple
remote_id attributes per Identity Provider objects. This is extremely
useful in configuring federations where 10s or 100s of Identity Provider
work within one federation and where one mapping ruleset is used among
them.
This has been discussed and widely accepted during Keystone mid cycle
meetup in January 2015. The first version of the implementation was
proposed on Febrary 2nd. During the implementation process we discovered
the bug (https://bugs.launchpad.net/keystone/+bug/1426334) that was
blocking further work. Fixing it took reasonably big manpower and
significantly delayed delivery process of the main feature. Eventually,
the bug was fixed and now we are ready to get final reviews (mind, the
patch was already reviewed and all the comments and issues were
constantly being addressed) and hopefully get landed in the Kilo release.
Specification link:
https://github.com/openstack/keystone-specs/blob/master/specs/kilo/idp-id-registration.rst
Implementation link: https://review.openstack.org/#/c/152156/
I hereby ask for exceptional accepting the provided work in the Kilo
release cycle.
With kind regards,
--
Marek Denis
Keystone Core member
__
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] Need help in configuring keystone
Akshik, When you are beginning an adventure with saml, shibboleth and so on, it's helpful to start with fetching auto-generated shibboleth2.xml file from testshib.org . This should cover most of your use-cases, at least in the testing environment. Marek __ 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] Need help in configuring keystone
Hi Akshik, Did you upload your Metadata file to the testshib server? You are advised to follow steps starting from here: http://testshib.org/register.html For the record, Keystone will act here as a Service Provider, so you need to follow testhib docs/tutorials for setting your SP (Service Provider) Let me know if that was your issue. If not, a more detailed steps of how your configured your Keystone acting as a Service Provider would be more helpful. Marek Denis On 27.02.2015 11:26, Akshik DBK wrote: Hi I'm new to SAML, trying to integrate keystone with SAML, Im using Ubuntu 12.04 with Icehouse, im following http://docs.openstack.org/developer/k... http://docs.openstack.org/developer/keystone/extensions/shibboleth.html when im trying to configure keystone with two idp, when i access https://MYSERVER:5000/v3/OS-FEDERATIO... https://myserver:5000/v3/OS-FEDERATION/identity_providers/idp_2/protocols/saml2/auth it gets redirected to testshib.org http://testshib.org/ , it prompts for username and password when the same is given im getting *shibsp::ConfigurationException at ( https://MYSERVER:5000/Shibboleth.sso/... https://myserver:5000/Shibboleth.sso/SAML2/POST ) No MetadataProvider available.* here is my shibboleth2.xml content |SPConfig xmlns=urn:mace:shibboleth:2.0:native:sp:config xmlns:conf=urn:mace:shibboleth:2.0:native:sp:config xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertion xmlns:samlp=urn:oasis:names:tc:SAML:2.0:protocol xmlns:md=urn:oasis:names:tc:SAML:2.0:metadata clockSkew=180 ApplicationDefaults entityID=https://MYSERVER:5000/Shibboleth; Sessions lifetime=28800 timeout=3600 checkAddress=false relayState=ss:mem handlerSSL=false SSO entityID=https://idp.testshib.org/idp/shibboleth; ECP=true SAML2 SAML1 /SSO LogoutSAML2 Local/Logout Handler type=MetadataGenerator Location=/Metadata signing=false/ Handler type=Status Location=/Status / Handler type=Session Location=/Session showAttributeValues=false/ Handler type=DiscoveryFeed Location=/DiscoFeed/ /Sessions Errors supportContact=root@localhost logoLocation=/shibboleth-sp/logo.jpg styleSheet=/shibboleth-sp/main.css/ AttributeExtractor type=XML validate=true path=attribute-map.xml/ AttributeResolver type=Query subjectMatch=true/ AttributeFilter type=XML validate=true path=attribute-policy.xml/ CredentialResolver type=File key=sp-key.pem certificate=sp-cert.pem/ ApplicationOverride id=idp_1 entityID=https://MYSERVER:5000/Shibboleth; Sessions lifetime=28800 timeout=3600 checkAddress=false relayState=ss:mem handlerSSL=false SSO entityID=https://portal4.mss.internalidp.com/idp/shibboleth; ECP=true SAML2 SAML1 /SSO LogoutSAML2 Local/Logout /Sessions MetadataProvider type=XML uri=https://portal4.mss.internalidp.com/idp/shibboleth; backingFilePath=/tmp/tata.xml reloadInterval=18 / /ApplicationOverride ApplicationOverride id=idp_2 entityID=https://MYSERVER:5000/Shibboleth; Sessions lifetime=28800 timeout=3600 checkAddress=false relayState=ss:mem handlerSSL=false SSO entityID=https://idp.testshib.org/idp/shibboleth; ECP=true SAML2 SAML1 /SSO LogoutSAML2 Local/Logout /Sessions MetadataProvider type=XML uri=https://idp.testshib.org/idp/shibboleth; backingFilePath=/tmp/testshib.xml reloadInterval=18/ /ApplicationOverride /ApplicationDefaults SecurityPolicyProvider type=XML validate=true path=security-policy.xml/ ProtocolProvider type=XML validate=true reloadChanges=false path=protocols.xml/ /SPConfig| here is my wsgi-keystone |WSGIScriptAlias /keystone/main/var/www/cgi-bin/keystone/main WSGIScriptAlias /keystone/admin/var/www/cgi-bin/keystone/admin Location /keystone # NSSRequireSSL SSLRequireSSL Authtype none /Location Location /Shibboleth.sso SetHandler shib /Location Location /v3/OS-FEDERATION/identity_providers/idp_1/protocols/saml2/auth ShibRequestSetting requireSession1 ShibRequestSetting applicationId idp_1 AuthType shibboleth ShibRequireAll On ShibRequireSession On ShibExportAssertion Off Require valid-user /Location Location /v3/OS-FEDERATION/identity_providers/idp_2/protocols/saml2/auth ShibRequestSetting requireSession1 ShibRequestSetting applicationId idp_2 AuthType shibboleth ShibRequireAll On ShibRequireSession On ShibExportAssertion Off Require valid-user /Location
Re: [openstack-dev] Error Enabling Federation Extension
Hi Akshik, Could you give some more details about the steps you did for configuring federation as well as the environment you are using? Is it devstack? What version of Keystone do you use? Thanks, Marek On 19.02.2015 12:52, Akshik DBK wrote: im getting “Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot be loaded as Python module” while configuring federation for keystone any help [info] [client 10.10.10.12] mod_wsgi (pid=25248, process=’keystone’, application=’10.1.193.250:5000|’): Loading WSGI script ‘/var/www/cgi-bin/keystone/main’. [error] [client 10.10.10.12] mod_wsgi (pid=25248): Target WSGI script ‘/var/www/cgi-bin/keystone/main’ cannot be loaded as Python module. [error] [client 10.10.10.12] mod_wsgi (pid=25248): Exception occurred processing WSGI script ‘/var/www/cgi-bin/keystone/main’. [error] [client 10.10.10.12] Traceback (most recent call last): [error] [client 10.10.10.12] File “/var/www/cgi-bin/keystone/main”, line 21, in [error] [client 10.10.10.12] config.configure() [error] [client 10.10.10.12] File “/usr/lib/python2.7/dist-packages/keystone/common/config.py”, line 694, in configure [error] [client 10.10.10.12] help=’Do not monkey-patch threading system modules.’)) [error] [client 10.10.10.12] File “/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1579, in __inner [error] [client 10.10.10.12] result = f(self, *args, **kwargs) [error] [client 10.10.10.12] File “/usr/lib/python2.7/dist-packages/oslo/config/cfg.py”, line 1731, in register_cli_opt [error] [client 10.10.10.12] raise ArgsAlreadyParsedError(“cannot register CLI option”) [error] [client 10.10.10.12] ArgsAlreadyParsedError: arguments already parsed: cannot register CLI option __ 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
Re: [openstack-dev] [keystone] SPFE: Authenticated Encryption (AE) Tokens
+1 from me. On 13.02.2015 22:19, Morgan Fainberg wrote: On February 13, 2015 at 11:51:10 AM, Lance Bragstad (lbrags...@gmail.com mailto:lbrags...@gmail.com) wrote: Hello all, I'm proposing the Authenticated Encryption (AE) Token specification [1] as an SPFE. AE tokens increases scalability of Keystone by removing token persistence. This provider has been discussed prior to, and at the Paris summit [2]. There is an implementation that is currently up for review [3], that was built off a POC. Based on the POC, there has been some performance analysis done with respect to the token formats available in Keystone (UUID, PKI, PKIZ, AE) [4]. The Keystone team spent some time discussing limitations of the current POC implementation at the mid-cycle. One case that still needs to be addressed (and is currently being worked), is federated tokens. When requesting unscoped federated tokens, the token contains unbound groups which would need to be carried in the token. This case can be handled by AE tokens but it would be possible for an unscoped federated AE token to exceed an acceptable AE token length (i.e. 255 characters). Long story short, a federation migration could be used to ensure federated AE tokens never exceed a certain length. Feel free to leave your comments on the AE Token spec. Thanks! Lance [1] https://review.openstack.org/#/c/130050/ [2] https://etherpad.openstack.org/p/kilo-keystone-authorization [3] https://review.openstack.org/#/c/145317/ [4] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ __ 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 I am for granting this exception as long as it’s clear that the following is clear/true: * All current use-cases for tokens (including federation) will be supported by the new token provider. * The federation tokens being possibly over 255 characters can be addressed in the future if they are not addressed here (a “federation migration” does not clearly state what is meant. I am also ok with the AE token work being re-ordered ahead of the provider cleanup to ensure it lands. Fixing the AE Token provider along with PKI and UUID providers should be minimal extra work in the cleanup. This addresses a very, very big issue within Keystone as scaling scaling up happens. There has been demand for solving token persistence for ~3 cycles. The POC code makes this exception possible to land within Kilo, whereas without the POC this would almost assuredly need to be held until the L-Cycle. TL;DR, I am for the exception if the AE Tokens support 100% of the current use-cases of tokens (UUID or PKI) today. —Morgan __ 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
Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team
Thank you, everyone! :) Dnia 13 lutego 2015 18:35:09 CET, Morgan Fainberg morgan.fainb...@gmail.com napisał(a): Based upon the feedback from this thread, I want to welcome Marek as the newest member of keystone core. Cheers, Morgan -- Morgan Fainberg On February 10, 2015 at 9:51:16 AM, Morgan Fainberg (morgan.fainb...@gmail.com) wrote: Hi everyone! I wanted to propose Marek Denis (marekd on IRC) as a new member of the Keystone Core team. Marek has been instrumental in the implementation of Federated Identity. His work on Keystone and first hand knowledge of the issues with extremely large OpenStack deployments has been a significant asset to the development team. Not only is Marek a strong developer working on key features being introduced to Keystone but has continued to set a high bar for any code being introduced / proposed against Keystone. I know that the entire team really values Marek’s opinion on what is going in to Keystone. Please respond with a +1 or -1 for adding Marek to the Keystone core team. This poll will remain open until Feb 13. -- Morgan Fainberg __ 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 -- Marek Denis [marek.de...@cern.ch] __ 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] [horizon][keystone]
Thai, We could also add an option in the Horizon's settings that automatically chooses one authentication workflow. At CERN we are trying to use websso with use of the SAML2 protocols as much as we can. That's said we automatically make users to use websso when they want to access their accounts via the dashboard. Hint: This is being done by automatic redirect to predefined Keystone endpoint once user hits our dashboard's URL). Marek On 05.02.2015 20:15, Thai Q Tran wrote: Hi Ioram, Thanks for the feedback. I agree that the names are hard to follow, they can change to something more intuitive. Or we can even provide a tooltip for more information. As for the look and feel, I don't agree that its easier if all the options are listed. Image if you had 5 different ways for users to log in and they are all shown at once. That's a lot to take in. This approach keep things simply, it's really not that hard to pick from a list. Hi Anton, I'm just building on top of the visuals we already have without changing things too drastically. If you have a better idea, I would love to see it. -Ioram Schechtman Sette i...@cin.ufpe.br wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Ioram Schechtman Sette i...@cin.ufpe.br Date: 02/05/2015 03:15AM Subject: Re: [openstack-dev] [horizon][keystone] Hi Thai, I agree with Anton that the names are not intuitive for users. I would use something like: - Local authentication (for local credentials) - ?? (I also have no idea of what is a Default protocol) - Authenticate using name of IdPs or federation (something which is easy to the user understand that he could use or not - this is for the discovery service or remote IdP) Here in the University of Kent we used another approach. Instead of selecting the method using a list/combo box, we present all the options in a single screen. I think it's not beautiful, but functional. I think it would be easier to the user if they could have all the options in a single interface, since it doesn't become too much loaded (visually polluted). Imagem inline 1 Regards, Ioram 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com mailto:azemlya...@mirantis.com: Hi, I guess Credentials is login and password. I have no idea what is Default Protocol or Discovery Service. The proposed UI is rather embarrassing. Anton On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com mailto:tqt...@us.ibm.com wrote: Hi all, I have been helping with the websso effort and wanted to get some feedback. Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service. If user selects credentials, it works exactly the same way it works today. If user selects default protocol or discovery service, they can choose to be redirected to those pages. Keep in mind that this is a prototype, early feedback will be good. Here are the relevant patches: https://review.openstack.org/#/c/136177/ https://review.openstack.org/#/c/136178/ https://review.openstack.org/#/c/151842/ I have attached the files and present them below: __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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://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 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 -- Marek Denis [marek.de...@cern.ch] __ 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
Re: [openstack-dev] [horizon][keystone]
Hi, I am more leaning towards layout Ioram suggested, but with protocols/other metods (Kerberos for instance) in the dropdown box. On 05.02.2015 17:16, Steve Martinelli wrote: Thanks Ioram, From the keystone side: the one issue with listing IdPs is that some may be private, so we're now looking to exploit the apache plugin data in the environment (https://review.openstack.org/#/c/142743/), thus from the horizon side the only data they need to send over would be the protocol that the IdP uses. What i'm taking away from some of the comments is to preserve the usual (username and password) flow, and maybe it'll be easier to just list off the protocols in a separate drop down (SAML and OpenID Connect). Steve Ioram Schechtman Sette i...@cin.ufpe.br wrote on 02/05/2015 06:04:36 AM: From: Ioram Schechtman Sette i...@cin.ufpe.br To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 02/05/2015 06:14 AM Subject: Re: [openstack-dev] [horizon][keystone] Hi Thai, I agree with Anton that the names are not intuitive for users. I would use something like: - Local authentication (for local credentials) - ?? (I also have no idea of what is a Default protocol) - Authenticate using name of IdPs or federation (something which is easy to the user understand that he could use or not - this is for the discovery service or remote IdP) Here in the University of Kent we used another approach. Instead of selecting the method using a list/combo box, we present all the options in a single screen. I think it's not beautiful, but functional. I think it would be easier to the user if they could have all the options in a single interface, since it doesn't become too much loaded (visually polluted). [image removed] Regards, Ioram 2015-02-05 9:20 GMT+00:00 Anton Zemlyanov azemlya...@mirantis.com: Hi, I guess Credentials is login and password. I have no idea what is Default Protocol or Discovery Service. The proposed UI is rather embarrassing. Anton On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran tqt...@us.ibm.com wrote: Hi all, I have been helping with the websso effort and wanted to get some feedback. Basically, users are presented with a login screen where they can select: credentials, default protocol, or discovery service. If user selects credentials, it works exactly the same way it works today. If user selects default protocol or discovery service, they can choose to be redirected to those pages. Keep in mind that this is a prototype, early feedback will be good. Here are the relevant patches: https://review.openstack.org/#/c/136177/ https://review.openstack.org/#/c/136178/ https://review.openstack.org/#/c/151842/ I have attached the files and present them below: [image removed] [image removed] [image removed] [image removed] __ 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 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 -- Marek Denis [marek.de...@cern.ch] __ 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] Nominating Brad Topol for Keystone-Spec core
+1 On 18.01.2015 20:11, Morgan Fainberg wrote: Hello all, I would like to nominate Brad Topol for Keystone Spec core (core reviewer for Keystone specifications and API-Specification only: https://git.openstack.org/cgit/openstack/keystone-specs ). Brad has been a consistent voice advocating for well defined specifications, use of existing standards/technology, and ensuring the UX of all projects under the Keystone umbrella continue to improve. Brad brings to the table a significant amount of insight to the needs of the many types and sizes of OpenStack deployments, especially what real-world customers are demanding when integrating with the services. Brad is a core contributor on pycadf (also under the Keystone umbrella) and has consistently contributed code and reviews to the Keystone projects since the Grizzly release. Please vote with +1/-1 on adding Brad to as core to the Keystone Spec repo. Voting will remain open until Friday Jan 23. Cheers, Morgan Fainberg -- Marek Denis [marek.de...@cern.ch] __ 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] Alternative federation mapping
Hi John, It indeed looks interesting and enhancing the mapping engine is on ours to-do list for a long time. I'd be happy to talk this through during the summit. Do you think you will be able to come for a Keystone websso/federation Design Session on Wednesday at 16.30? Thanks, Marek On 02.11.2014 18:29, John Dennis wrote: While working on federated authentication for a different project (OpenDaylight) we discovered we needed to map from the assertion provided by an external federated IdP to local values. This is essentially the same requirement which exists in Keystone's federated support. It was hoped we could simply borrow the Keystone mapping implementation but it was found to be too limiting and not sufficiently expressive. We could not find another alternative so we designed a new mapper which is described in this PDF. https://jdennis.fedorapeople.org/doc/mapping.pdf The mapper as described in the document has implementations in both Java and Python. The Java implementation is currently in use in OpenDaylight (a Java based project). For those interested I can provide a pointer to OpenDaylight specific documentation on how this mapper is used in conjunction with the Apache web server providing authentication and SSSD providing identity attributes to a Java servlet container. My goal here is to make Keystone developers aware of an alternative mapper which may provide needed mapping features not currently available and for which different language implementations already exist. Note, the mapper is easily extended should a need arise. Source code and documentation can be found here by cloning this git repo: git clone git://fedorapeople.org/~jdennis/federated-mapping.git Note, I put this git repo together quickly by pulling together things from a variety of sources, as such there may be things needing to be cleaned up in the repo, at the moment it's really just meant to browse. Over the next few days I'll make sure everything builds and executes cleanly. Posting this now in case folks want to have conversations at the Paris Summit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
On 17.09.2014 15:45, Steve Martinelli wrote: ++ to your suggestion David, I think making the list of trusted IdPs publicly available makes sense. I think this might be useful in an academic/science world but on the other hand most cloud providers from the 'business' world might be very reluctant to expose list of their clients for free. cheers, Marek. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi,
First of all, we should clarify whether your JS client wants to
implement ECP or WebSSO workflow. They are slightly different.
I feel JS is smart enough to implement the ECP flow and then and it
could simply implement what we already have in the keystoneclient [0].
This + some discovery service described by Adam would be required.
However, some problems may arise when it comes to ADFS support (we
needed separate plugin in keystoneclient) and other protocols which
should work by default from browsers.
[0]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon to return a generic login page, with a button that
says Or do Federated
2. Use clicks that button and gets the Federated UI. No new HTTP
request needed for this, still just static Javascript. Form has an edit
field for the user to enter the SAML IdP, anda button to fetch the list
of the public IdPs from Keystone.
3. Assume user clicks the list of public IdPs, those fill out a
drop-down box. If the user clicks on one, it populates the textbox with
the URL for the IdP.
3a. However, if the users IdP is not in the list, they go back to the
email they got from their IT guy that has Paste this URL into the IdP
edit box
Well, we don't keep any IdPs' URL in Keystone backend at the moment.
However, this can be easily fixed.
4. User clicks OK.
OK
Window pops up with the WebUI for the user to visit the SAML IdP URL.
This will be of the form
|
GET
htps://keystone/main/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth|
Which will perform the necessary redirects to get the user the SAML
assertion, and return it to Keystone.
Let's assume this step would work for now. I am interested how would the
SP-IDP-SP workflow look like from the JS perspective. In classic WebSSO,
where user uses only his browser:
1) Go to the protected resource
(/v3/OS-FEDERATION/identity_providers/{identity_provider}/protocols/{protocol}/auth
in our case)
2) (skipping the DS step for now) get redirected to the IdP
3) Authenticate with the IdP
4) Get redirected to the SP
5) Read your protected content, because you have been authenticated and
authorized to do so (get an unscoped, federated token issued by Keystone
in our case)
Now, I can imagine, if that's the websso approach can we somehow make JS
mimic the browser with all its blessing? So the user would actualy see
the real HTML website? If so, that would be enough to make it work.
5. Javascript picks up the Federated unscoped token from the response
at the end of step 4 and use that to get a scoped token.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] - Cloud federation on top of the Apache
On 29.01.2014 17:06, Adam Young wrote:
We had a team member looking into SAML, but I don't don't know if he
made that distinction.
Do you think he would be willing to give a helping hand and share his
expertise? Any possibility to contact your colleague? Without ECP/http
clients extensions i think the federation is only 50% useful (because
eventually somehow you need to login and obtain the saml assertion
manually, with your browser).
Is there anything that would prevent us from having a solution that
supported both, based on the requirements of the implementer?
mod_shib passes saml assertion parameters into discrete environment
variables. I am now looking at the mod_mellon README file and it looks
like mellon's behaviour is pretty much the same. So, if there any
implementation details, they are minor ones and we basically start at
the same page.
From https://modmellon.googlecode.com/svn/trunk/mod_mellon2/README :
===
Using mod_auth_mellon
===
After you have set up mod_auth_mellon, you should be able to visit (in our
example) https://example.com/secret/, and be redirected to the IdP's login
page. After logging in you should be returned to
https://example.com/secret/, and get the contents of that page.
When authenticating a user, mod_auth_mellon will set some environment
variables to the attributes it received from the IdP. The name of the
variables will be MELLON_attribute name. If you have specified a
different name with the MellonSetEnv or MellonSetEnvNoPrefix configuration
directive, then that name will be used instead. In the case of MellonSetEnv,
the name will still be prefixed by 'MELLON_'.
The value of the attribute will be base64 decoded.
mod_auth_mellon supports multivalued attributes with the following format:
base64 encoded value_base64 encoded value_base 64 encoded value...
If an attribute has multiple values, then they will be stored as
MELLON_name_0, MELLON_name_1, MELLON_name_2, ...
Since mod_auth_mellon doesn't know which attributes may have multiple
values, it will store every attribute at least twice. Once named
MELLON_name, and once named MELLON_name_0.
In the case of multivalued attributes MELLON_name will contain the first
value.
The following code is a simple php-script which prints out all the
variables:
?php
header('Content-Type: text/plain');
foreach($_SERVER as $key=$value) {
if(substr($key, 0, 7) == 'MELLON_') {
echo($key . '=' . $value . \r\n);
}
}
?
--
Marek Denis
[marek.de...@cern.ch]
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] - Cloud federation on top of the Apache
On 28.01.2014 21:44, Adam Young wrote: To be clear, are you going to use mod_mellon as the Apache Auth module? I am leaning towards mod_shib, as at least in theory it handles ECP extension. And I am not so sure mod_mellon does. Adam, do you have at RedHat any experience with ECP SAML extensions or you used only webSSO? -- Marek Denis [marek.de...@cern.ch] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] - Cloud federation on top of the Apache
Dear all,
We have Identity Provider and mapping CRUD operations already merged, so
it's a good point to prepare Keystone and Apache to handle SAML (as a
starter) requests/responses.
For the next OpenStack release it'd be the Apache that handles SAML
communication. In order to force SAML authentication, an admin defines
so called 'protected resources', hidden behind certain URLs. In order to
get access to aforementioned resources a SAML authenticated session is
required. In terms of Keystone and federation this 'resource' would be
just a token, ready to be later used against other OpenStack services.
For obvious reasons we cannot make mod_shib watch all the Keystone URLs
clients can access, so I think a dedicated URL should be used. That's
right, a client who'd want to grab a token upon SAML authn would need to
hit
https://keystone:5000/v3/OS-FEDERATION/tokens/identity_provider/idp/protocol/protocol
.Such a URL would albo be kind of dynamic, because this would later let
Keystone distinguish* what (already registered) IdP and federation
protocol (SAML, OpenID, etc) is going to be used .
A simplified workflow could look like this:
Pre-req: Apache frontend is configured to protect URLs matching regex
/OS-FEDERATION/tokens/identity_provider/(.*?)/protocol/(.*?)
1) In order to get a valid token upon federated authentication a client
enters protected resource, for instance
https://keystone:5000/v3/OS-FEDERATION/tokens/identity_provider/{idp}/protocol/{protocol}
2) After the client is authenticated (with ECP/similar extension) the
request enters Keystone public pipeline.
3) Apache modules store parsed parameters from a SAML assertion in a
wsgi environment,
4) A class inheriting from wsgi.Middleware checks whether the
REQUEST_URL (or similar) environment variable matches aforementioned
regexp (e.g. /OS-FEDERATION/tokens/identity_provider/.*?/protocol/.*?)
and if the match is positive, fetches env parameters starting with
certain value (a prefix configurable in the keystone.conf, say 'ADFS_'
). The parameters are stored as a dictionary and passed in a structure,
later available to other filters/middleware objects in the pipeline (TO
BE CONFIRMED, MAYBE REWRITING PARAMS IS NOT REQUIRED).
5) keystone/contrib/federation/routers.py has defined URL routes and
fires keystone/contrib/federation/controllers.py methods that fetch IdP,
protocol entities as well as the corresponding mapping entity with the
mapping rules included. The rules are applied on the assertion
parameters and list of local users/groups is issued. The OpenStack token
is generated, stored in the DB and returned to the user (formed as a
valid JSON response).
6) The token can now be used for next operations on the OpenStack cloud.
*)
At first I though the dynamic URLs
(OS-FEDERATION/tokens/identity_provider/(.*?)/protocol/(.*?)) could be
replaced with a one static, and information about the IdP and protocol
could be sent as a HTTP POST input, but from what I have already noticed
after the client is redirected to the IdP (and to the SP again) the
initial input is lost.
I am looking forward to hear feedback from you.
Thanks,
--
Marek Denis
[marek.de...@cern.ch]
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Testing before sending for review
Hey, On 23.10.2013 11:29, Rosa, Andrea (HP Cloud Services) wrote: Usually I find always useful to test my changes in devstack. How do you do that? I think the devstack does not always contain up to date codebase does it, so what would be the point in testing changes on the old code? Thanks for the reply. -- Marek Denis [marek.de...@cern.ch] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
