Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation
On Thu, Apr 21, 2016 at 10:22:46AM -0400, John Dennis wrote: > On 04/18/2016 12:34 PM, Martin Millnert wrote: > >(** ECP is a new feature, not supported by all IdP's, that at (second) > >best requires reconfiguration of core authentication services at each > >customer, and at worst requires customers to change IdP software > >completely. This is a varying degree of showstopper for various > >customers.) > > The majority of work to support ECP is in the SP, not the IdP. In fact IdP's > are mostly agnostic with respect to ECP, there is nothing ECP specific an > IdP must implement other than supporting the SOAP binding for the > SingleSignOnService which is trivial. I've yet to encounter an IdP that does > not support the SOAP binding. > > What IdP are you utilizing which is incapable of receiving an AuthnRequest > via the SOAP binding? > I would disagree on this. Last year in EduGAIN, the European interfederation including hundreds of IdPs, only a very small amount were supporting ECP. I did a check on the metadata. Additionally, some IdP implementations do not support ECP out-of-the-box and for the one providing such support, it requires a different authentication mechanism compared to the one used for the redirect or post profile so many IdPs are not supporting this mechanism. The work to support ECP is equally distributed among the IdP and SP although it is getting more common in the IdPs with last release of IdPs software such as shibboleth IdP v3. Marco > > -- > 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 smime.p7s Description: S/MIME cryptographic signature __ 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] [nova][all] Architecture Diagrams in ascii art?
+1 I prefer the ascii art in the specs and/or code doumentation. Figures could be better in other contexts like user and administrator manuals but they should not go in the code repository in my opinion. Cheers, Marco Fargetta On Mon, May 11, 2015 at 09:11:24PM -0400, Steve Martinelli wrote: The Keystone team actually uses ascii diagrams in some of our specs, [0] for instance. I might be in the minority here, but I actually like them and find the easy to create and read. [0] http://specs.openstack.org/openstack/keystone-specs/specs/kilo/websso-portal.html Thanks, Steve Martinelli OpenStack Keystone Core Joe Gordon joe.gord...@gmail.com wrote on 05/11/2015 05:57:48 PM: From: Joe Gordon joe.gord...@gmail.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 05/11/2015 05:59 PM Subject: [openstack-dev] [nova][all] Architecture Diagrams in ascii art? When learning about how a project works one of the first things I look for is a brief architecture description along with a diagram. For most OpenStack projects, all I can find is a bunch of random third party slides and diagrams. Most Individual OpenStack projects have either no architecture diagram or ascii art. Searching for 'OpenStack X architecture' where X is any of the OpenStack projects turns up pretty sad results. For example heat [0] an Keystone [1] have no diagram. Nova on the other hand does have a diagram, but its ascii art [2]. I don't think ascii art makes for great user facing documentation (for any kind of user). So how can we do better then ascii art architecture diagrams? [0] http://docs.openstack.org/developer/heat/architecture.html [1] http://docs.openstack.org/developer/keystone/architecture.html [2] http://docs.openstack.org/developer/nova/devref/architecture.html __ 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 smime.p7s Description: S/MIME cryptographic signature __ 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] - IdP ID (remote_id) registration and validation
This is a good workaround to allow the authentication on the IdP but with the
new websso is problematic because
you do not know which mapping to use but you have the Shib-Identity-Provider.
With the new information
the entityIDs are associated with the keystone IdP so it is easy to find the
right one. With this approach
you have to analyse all the mapping and select the first that can apply.
Marco
On Wed, Mar 18, 2015 at 05:54:36PM +, Yee, Guang wrote:
I think we can create a mapping which restricts which IdP it is applicable.
When playing around with K2K, I've experimented with multiple IdPs. I
basically chained the IdPs in shibboleth2.xml like this
MetadataProvider type=Chaining
MetadataProvider type=XML file=/etc/keystone/acme_idp_metadata.xml/
MetadataProvider type=XML file=/etc/keystone/beta_idp_metadata.xml/
/MetadataProvider
And with a mapping intended for Acme IdP, we can ensure that only Acme users
can map to group '1234567890'.
{
mapping: {
rules: [
{
local: [
{
user: {
name: {0}
}
},
{
group: {
id: 1234567890
}
}
],
remote: [
{
type: openstack_user
},
{
type: Shib-Identity-Provider,
any_one_of: [
https://acme.com/v3/OS-FEDERATION/saml2/idp;
]
}
]
}
]
}
}
Shibboleth do convey the Shib-Identity-Provider attribute in the request
environment. With this mechanism we should be able to create a rule for
multiple IdPs as well.
Guang
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Wednesday, March 18, 2015 2:41 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][FFE] - IdP ID (remote_id)
registration and validation
In my opinion you have got into this situation because your federation trust
model is essentially misguided. As I have been arguing since the inception of
federated Keystone, you should have rules for trusted IdPs (already done),
trusted attributes (not done), and then one set of mapping rules that apply
to all IdPs and all attributes (not done). If you had followed this model
(the one Kent originally implemented) you would not be in this situation now.
Concerning the remote user ID, we can guarantee that it is always globally
unique by concatenating the IDP name with the IdP issued user ID, so this
wont cause a problem in mapping rules.
Concerning other identity attributes, there are two types:
- globally known and assigned attributes (such email address and other LDAP
ones) that have unique IDs regardless of the IDP that issued them - the
eduPerson schema attributes are of this type, so the mapping rules for these
are IDP independent, and the trusted IDP rules ensure that you filter out
untrusted ones
- locally issued attributes that mean different things to different IDPs. In
this case you need to concatenate the name of the IDP to the attribute to
make it globally unique, and then the mapping rules will always apply. The
trusted IDP rules will again filter these out or let them pass.
So instead of fixing the model, you are adding more layers of complexity to
the implementation in order to fix conceptual errors in your federation model.
Sadly yours
David
On 17/03/2015 22:28, Marek Denis wrote:
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).
Re: [openstack-dev] Need help in configuring keystone
Hi Akshik, the metadata error is in your SP, if the error was on testshib you should not be redirected back after the login. Maybe there is a configuration problem with shibboleth. Try to restart the service and look at shibboleth logs. Check also the metadata of testshib are downloaded correctly because from the error it seems you have not the metadata of testshib. Cheers, Marco On Fri, Feb 27, 2015 at 06:39:30PM +0530, Akshik DBK wrote: Hi Marek , I've registered with testshib, this is my keystone-apache-error.log log i get [error] [client 121.243.33.212] No MetadataProvider available., referer: https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO From: aks...@outlook.com To: openstack-dev@lists.openstack.org Date: Fri, 27 Feb 2015 15:56:57 +0530 Subject: [openstack-dev] Need help in configuring keystone 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...when im trying to configure keystone with two idp,when i access https://MYSERVER:5000/v3/OS-FEDERATIO...it gets redirected to testshib.org , it prompts for username and password when the same is given im gettingshibsp::ConfigurationException at ( https://MYSERVER:5000/Shibboleth.sso/... ) No MetadataProvider available.here is my shibboleth2.xml contentSPConfig 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/ /SPConfighere is my wsgi-keystoneWSGIScriptAlias /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 requireSession 1 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 requireSession 1 ShibRequestSetting applicationId idp_2 AuthType shibboleth ShibRequireAll On ShibRequireSession On
Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone Core Team
+1 Well done! On Tue, Feb 10, 2015 at 09:51:14AM -0800, Morgan Fainberg 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 -- 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 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] Bug in federation
Hi David, in principle I agree with your comments. The current design mixes different aspect up and it is not manageable when the number of IdPs get bigger, like in the case you should allow access from users in a country federation, especially compared to other tools supporting identity federation. Nevertheless, I think you have to consider the current implementation like a fusion between the discovery protocol and the authentication. Users, instead of being re-directed to a Discovery Service providing the list of IdPs, receive the list from keystone itself. Each endpoint URL is an IdP the user can use to authenticate and when selected the user should go directly to the IdP and not into the DS. Of course I am not saying this is good but it is acceptable from the user point of view. There is not the problem to map IdPs in the DS with endpoint URL because it is made in advance. By the way, if you change the approach and create a single URL for the authentication then I cannot see the use of a list of trusted IdPs. You should disable the not accepted IdPs at higher level so to avoid the situation where a user authenticate into the IdP but cannot access the service. You may work at apache and DS level to enable only trusted IdPs. Then you need a better mapping in order to put your logic there. I think this is a significant change and if there is agreement I think it is possible to end with a more flexible design. Do you plan to propose a new spec? Marco On Fri, Jan 02, 2015 at 09:51:55PM +, David Chadwick wrote: Hi Marco I think the current design is wrong because it is mixing up access control with service endpoint location. The endpoint of a service should be independent of the access control rules determining who can contact the service. Any entity should be able to contact a service endpoint (subject to firewall rules of course, but this is out of scope of Keystone), and once connected, access control should then be enforced. Unfortunately the current design directly ties access control (which IdP) to the service endpoint by building the IDP name into the URL. This is fundamentally a bad design. Not only is it too limiting, but also it is mixing up different concerns, rather than separating them out, which is a good computer science principle. So, applying the separation of concerns principle to Keystone, the federated login endpoint should not be tied to any specific IdP. There are many practical reasons for this, such as: a) in the general case the users of an openstack service could be from multiple different organisations, and hence multiple different IdPs, but they may all need to access the same service and hence same endpoint, b) users who are authorised to access an openstack service might be authorised based on their identity attributes that are not IdP specific (e.g. email address), so they might have a choice of IDP to use c) federations are getting larger and larger, and interfederations are exploding the number of IdPs that users can use. The GEANT eduGAIN interfederation for example now has IdPs from about 20 countries, and each country can have over a 100 IdPs. So we are talking about thousands of IdPs in a federation. It is conceivable that users from all of these might wish to access a given cloud service. Here is my proposal for how federation should be re-engineered 1. The federation endpoint URL for Keystone can be anything intuitive and in keeping with existing guidelines, and should be IDP independent 2. Apache will protect this endpoint with whatever federation protocol(s) it is able to. The Keystone administrator and Apache administrator will liaise out of band to determine the name of the endpoint and the federation protocol and IDPs that will be able to access it. 3. Keystone will have its list of trusted IdPs as now. 4. Keystone will have its mapping rules as now (although I still believe it would be better for mapping rules to be IDP independent, and to have lists of trusted attributes from trusted IDPs instead) 5. Apache will return to Keystone two new parameters indicating the IdP and protocol that were used by the user in connecting to the endpoint. Apache knows what these are. 6. Keystone will use these new parameters for access control and mapping rules. i.e. it will reject any users who are from untrusted IdPs, and it will determine the right mapping rule to use based on the values of the two new parameters. A simple table in Keystone will map the IdPs and protocols into the correct mapping rule to use. This is not a huge change to make, in fact it should be a rather simple re-engineering task. regards David On 24/12/2014 17:50, Marco Fargetta wrote: On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote: If I understand the bug fix correctly, it is firmly tying the URL to the IDP to the mapping rule. But I think this is going in the wrong
Re: [openstack-dev] [Keystone] Bug in federation
into Keystone, are actually being followed by Apache. Trust but verify in the words of Ronald Regan. regards David —Morgan regards David On the Apache side we are looking to expand the set of variables set. http://www.freeipa.org/page/Environment_Variables#Proposed_Additional_Variables The original SAML assertion mod_shib does support Shib-Identity-Provider : https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess#NativeSPAttributeAccess-CustomSPVariables Which should be sufficient: if the user is coming in via mod_shib, they are using SAML. BTW, we are using the Juno release. We should fix this bug in Kilo. As I have been saying for many months, Keystone does not know anything about SAML or ABFAB or OpenID Connect protocols, so there is currently no point in configuring this information into Keystone. Keystone is only aware of environmental parameters coming from Apache. So this is the protocol that Keystone recognises. If you want Keystone to try to control the federation protocol and IDPs used by Apache, then you will need the Apache plugins to pass the name of the IDP and the protocol being used as environmental parameters to Keystone, and then Keystone can check that the ones that it has been configured to trust, are actually being used by Apache. regards David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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] Bug in federation
On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote: If I understand the bug fix correctly, it is firmly tying the URL to the IDP to the mapping rule. But I think this is going in the wrong direction for several reasons: 1. With Shibboleth, if you use a WAYF service, then anyone from hundreds of different federated IDPs may end up being used to authenticate the user who is accessing OpenStack/Keystone. We dont want to have hundreds of URLs. One is sufficient. Plus we dont know which IDP the user will eventually choose, as this is decided by the WAYF service. So the correct URL cannot be pre-chosen by the user. With the proposed configuration of shibboleth when you access the URL then you are redirect only to the IdP configured for the URL. Since a URL is tied to only an IDP there is not need of a WAYF. Anyway, this is a change only in the documentation and it was the first fix because there was an agreement to provide a solution also for Juno with the minimal change in the code. The other fix I proposed, which is under review, requires an additional parameter when you configure the IdP in OS-Federation. This accepts one or more EntityIDs so you can map the entities with the URL. This also requires to specify the http variable where you can get the entityID (this is a parameter so it can be compatible with different SAML plug-ins). If you do not specify these values the behaviour is like the current implementation otherwise providing the list of entities and the parameter the access to the URL is allowed only to the IDP included in the list and the other are rejected. I tried to be more compatible with the current implementation as possible. Is this in the right direction? Could you comment on the review page? It will be better to understand it the patch need extra work. The link is: https://review.openstack.org/#/c/142743/ 2. With ABFAB, the IDP to be used is not known by the SP (Keystone) until after authentication. This is because the realm is incorporated in the user's ID (u...@real.com) and this is not visible to Keystone. So it is not possible to have different URLs for different IDPs. They all have to use the same URL. So there should be one URL protecting Keystone, and when the response comes from Apache, Keystone needs to be able to reliably determine a) which IDP was used by the user b) which protocol was used and from this, choose which mapping rule to use This would require a new design of the OS-Federation and you have proposed several specs I was agreeing with. Nevertheless, it seems there was not consensus in the community so I think you have to find a way to integrate ABFAB with the current model. Is it possible to have a single mapping with many rules and keystone chose according to the information coming after the authentication? Maybe this require to work on the mapping but it does not require changes in the overall architecture, just an idea. regards david On 24/12/2014 10:19, Marco Fargetta wrote: Hi All, this bug was already reported and fixed in two steps: https://bugs.launchpad.net/ossn/+bug/1390124 The first step is in the documentation. There should be also an OSS advice for previous version of OpenStack. The solution consist in configuring shibboleth to use different IdPs for different URLs. The second step, still in progress, is to include an ID in the IdP configuration. My patch is under review here: https://review.openstack.org/#/c/142743/ Let me know if it is enough to solve the issue in your case. Marco On 24 Dec 2014, at 10:08, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 23/12/2014 21:56, Morgan Fainberg wrote: On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com mailto:dolph.math...@gmail.com wrote: On Tue, Dec 23, 2014 at 1:33 PM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: Hi Adam On 23/12/2014 17:34, Adam Young wrote: On 12/23/2014 11:34 AM, David Chadwick wrote: Hi guys we now have the ABFAB federation protocol working with Keystone, using a modified mod_auth_kerb plugin for Apache (available from the project Moonshot web site). However, we did not change Keystone configuration from its original SAML federation configuration, when it was talking to SAML IDPs, using mod_shibboleth. Neither did we modify the Keystone code (which I believe had to be done for OpenID connect.) We simply replaced mod_shibboleth with mod_auth_kerb and talked to a completely different IDP with a different protocol. And everything worked just fine. Consequently Keystone is broken, since you can configure it to trust a particular IDP, talking a particular protocol, but Apache will happily talk to another IDP, using a different protocol, and Keystone cannot tell the difference and will happily accept the authenticated user. Keystone should reject any authenticated user who
Re: [openstack-dev] [Keystone] Bug in federation
Hi John, the problem is not to establish which variable has the correct information but the association between IDP and URL. In OS-Federation you define an authentication URL per IDP and protocol and it is supposed to use the specified IDP and protocol for authenticate. Nevertheless, during the authentication there is not code to check if the IDP and protocol are the one specified for the URL and in the apache configuration for Juno there was no configuration in the apache side to bind the IDP with the URL. Therefore, you need to add something in OS_Federation to perform this control using the variable you are proposing or others. Marco On 24 Dec 2014, at 15:15, John Dennis jden...@redhat.com wrote: Can't this be solved with a couple of environment variables? The two keys pieces of information needed are: 1) who authenticated the subject? 2) what authentication method was used? There is already precedence for AUTH_TYPE, it's used in AJP to initialize the authType property in a Java Servelet. AUTH_TYPE would cover item 2. Numerous places in Apache already set AUTH_TYPE. Perhaps there could be a convention that AUTH_TYPE could carry extra qualifying parameters much like HTTP headers do. The first token would be the primary mechanism, e.g. saml, negotiate, x509, etc. For authentication types that support multiple mechanisms (e.g. EAP, SAML, etc.) an extra parameter would qualify the actual mechanism used. For SAML that qualifying extra parameter could be the value from AuthnContextClassRef. Item 1 could be covered by a new environment variable AUTH_AUTHORITY. If AUTH_TYPE is negotiate (i.e. kerberos) then the AUTH_AUTHORITY would be the KDC. For SAML it would probably be taken from the AuthenticatingAuthority element or the IdP entityID. I'm not sure I see the need for other layers to receive the full SAML assertion and validate the signature. One has to trust the server you're running in. It's the same concept as trusting REMOTE_USER. -- John ___ 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] [Horizon][Keystone] Steps toward Kerberos and Federation
Hi, I am wondering if the solution I was trying to sketch with the spec https://review.openstack.org/#/c/96867/13; is not easier to implement and manage then the steps highlated till n.2. Maybe, the spec is not yet there and should be improved (I will abandon or move to Kilo as Marek suggest) but the overall schema I think it is better then try to complicate the communication between Horizon and Keystone, IMHO. Step 3 is a different story and it needs more evaluation of the possible scenarios opened. Cheers, Marco On Thu, Sep 04, 2014 at 05:37:38PM -0400, Adam Young wrote: While the Keystone team has made pretty good strides toward Federation for getting a Keystone token, we do not yet have a complete story for Horizon. The same is true about Kerberos. I've been working on this, and I want to inform the people that are interested in the approach, as well as get some feedback. My first priority has been Kerberos. I have a proof of concept of this working, but the amount of hacking I had to Django-OpenStack-Auth (DOA) made me shudder: its fairly ugly. A few discussions today have moved things such that I think I can clean up the approach. Phase 1. DOA should be able to tell whether to use password or Kerberos in order to get a token from Keystone based on an variable set by the Apache web server; mod_auth_kerb will set request.META['KRB5CCNAME'] only in the kerberos case. If it gets this variable, DOA will only do Kerberos. If it does not, it will only do password. There will be no fallback from Kerberos to password; this is enforced by mod_auth_kerb, not something we can easily hack around in Django. That gets us Kerberos, but not Federation. Most of the code changes are common with what follows after: Phase 1.5. Add an optional field to the password auth page that allows a user to log in with a token instead of userid/password. This can be a hidden field by default if we really want. DOA now needs to be able to validate a token. Since Horizon only cares about the hashed version of the tokens anyway, we only to Online lookup, not PKI token validation. In the successful response, Keystone will to return the properly hashed (SHA256 for example) of the PKI tokens for Horizon to cache. Phase 2. Use AJAX to get a token from Keystone instead of sending the credentials to the client. Then pass that token to Horizon in order to login. This implies that Keystone has set up CORS support. This will open the door for Federation. While it will provide a different path to Kerberos than the stage 1, I think both are valuable approaches and will serve different use cases. This Phase 3. Never send your token to Horizon. In this world, the browser, with full CORS support, makes AJAX calls direct to Nova, Glance, and all other services. Yep, this should be a cross project session for the summit. ___ 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][Horizon] Proposed Changed for Unscoped tokens.
On Fri, Jul 04, 2014 at 06:13:30PM -0400, Adam Young wrote:
Unscoped tokens are really a proxy for the Horizon session, so lets
treat them that way.
1. When a user authenticates unscoped, they should get back a list
of their projects:
some thing along the lines of:
domains [{ name = d1,
projects [ p1, p2, p3]},
{ name = d2,
projects [ p4, p5, p6]}]
Not the service catalog. These are not in the token, only in the
response body.
2. Unscoped tokens are only initially via HTTPS and require client
certificate validation or Kerberos authentication from Horizon.
Unscoped tokens are only usable from the same origin as they were
originally requested.
3. Unscoped tokens should be very short lived: 10 minutes.
Unscoped tokens should be infinitely extensible: If I hand an
unscoped token to keystone, I get one good for another 10 minutes.
Using this time limit horizon should extend all the unscoped token
every x min (with x 10). Is this useful or could be long lived but
revocable by Keystone? In this case, after the unscoped token is
revoked it cannot be used to get a scoped token.
4. Unscoped tokens are only accepted in Keystone. They can only be
used to get a scoped token. Only unscoped tokens can be used to get
another token.
Comments?
___
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][Horizon] Proposed Changed for Unscoped tokens.
3. Unscoped tokens should be very short lived: 10 minutes. Unscoped tokens should be infinitely extensible: If I hand an unscoped token to keystone, I get one good for another 10 minutes. Using this time limit horizon should extend all the unscoped token every x min (with x 10). Is this useful or could be long lived but revocable by Keystone? In this case, after the unscoped token is revoked it cannot be used to get a scoped token. Close. I was thinking more along the lines of Horizon looking at the unscoped token and, if it is about to expire, exchanging one unscoped token for another. The unscoped tokens would have a short time-to-live (10 minutes) and any scoped tokens they create would have the same time span: we could in theory make the unscoped last longer, but I don't really think it would be necessary. When should Horizon check the token validity? If it depends from external events, like user interactions, I think the time-frame should be similar to the user session to avoid the need of authenticate users many times inside the session. If you use an external thread to renew the token then they could be shorter but this would generate some traffic to evaluate. 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
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] Redesign of Keystone Federation
Hi David and Kristy, looking at the slides it is not clear to me why you need to have an authn plugin for each Apache plugin. I have experience only with few Apache plugins and they provide the possibility to customise the attributes for the application behind. As an example, with mod_shib it is possible to define how the information coming from the IdP should be provided to the application. Maybe this is not possible with all plugins but I am wondering if it is possible the other way around. In other words, to create only a configurable authn plugin for all apache plugin. In the configuration you should provide the name of the attributes to look at and the mapping with the Keystone attributes. BTW: design 2 seems better although requires more work. Cheers, Marco On Wed, May 28, 2014 at 04:59:48PM +0100, David Chadwick wrote: Hi Everyone at the Atlanta meeting the following slides were presented during the federation session http://www.slideshare.net/davidwchadwick/keystone-apach-authn It was acknowledged that the current design is sub-optimal, but was a best first efforts to get something working in time for the IceHouse release, which it did successfully. Now is the time to redesign federated access in Keystone in order to allow for: i) the inclusion of more federation protocols such as OpenID and OpenID Connect via Apache plugins ii) federating together multiple Keystone installations iii) the inclusion of federation protocols directly into Keystone where good Apache plugins dont yet exist e.g. IETF ABFAB The Proposed Design (1) in the slide show is the simplest change to make, in which the Authn module has different plugins for different federation protocols, whether via Apache or not. The Proposed Design (2) is cleaner since the plugins are directly into Keystone and not via the Authn module, but it requires more re-engineering work, and it was questioned in Atlanta whether that effort exists or not. Kent therefore proposes that we go with Proposed Design (1). Kent will provide drafts of the revised APIs and the re-engineered code for inspection and approval by the group, if the group agrees to go with this revised design. If you have any questions about the proposed re-design, please don't hesitate to ask regards David and Kristy ___ 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 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] Replication multi cloud
Thanks Donagh, I will take a look to the ontainer-to-container synchronization to understand if it fits with my scenario. Cheers, Marco On Thu, Mar 13, 2014 at 03:28:03PM +, McCabe, Donagh wrote: Marco, The replication *inside* Swift is not intended to move data between two different Swift instances -- it's an internal data repair and rebalance mechanism. However, there is a different mechanism, called container-to-container synchronization that might be what you are looking for. It will sync two containers in different swift instances. The swift instances may be in different Keystone administrative domains -- the authentication is not based on Keystone. It does require that each swift instance be configured to recognise each other. However, this is only usable for low update rates. Regards, Donagh -Original Message- From: Fargetta Marco [mailto:marco.farge...@ct.infn.it] Sent: 13 March 2014 11:24 To: OpenStack Development Mailing List Subject: [openstack-dev] [swift] Replication multi cloud Hi all, we would use the replication mechanism in swift to replicate the data in two swift instances deployed in different clouds with different keystones and administrative domains. Is this possible with the current replication facilities or they should stay in the same cloud sharing the keystone? Cheers, Marco -- Eng. Marco Fargetta, PhD Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy EMail: marco.farge...@ct.infn.it ___ 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] Replication multi cloud
Hi Chmouel, using this approach should I need to have the same users in both keystone? Is there any way to map user A from cloud X to user B in cloud Y? Our clouds have different users and replicates the keystone could have some problems, not only technical. Cheers, Marco On Thu, Mar 13, 2014 at 06:19:29PM +0100, Chmouel Boudjnah wrote: You may be interested by this project as well : https://github.com/stackforge/swiftsync you would need to replicate your keystone in both way via mysql replication or something like this (and have endpoint url changed as well obviously there). Chmouel On Thu, Mar 13, 2014 at 5:25 PM, Marco Fargetta marco.farge...@ct.infn.itwrote: Thanks Donagh, I will take a look to the ontainer-to-container synchronization to understand if it fits with my scenario. Cheers, Marco On Thu, Mar 13, 2014 at 03:28:03PM +, McCabe, Donagh wrote: Marco, The replication *inside* Swift is not intended to move data between two different Swift instances -- it's an internal data repair and rebalance mechanism. However, there is a different mechanism, called container-to-container synchronization that might be what you are looking for. It will sync two containers in different swift instances. The swift instances may be in different Keystone administrative domains -- the authentication is not based on Keystone. It does require that each swift instance be configured to recognise each other. However, this is only usable for low update rates. Regards, Donagh -Original Message- From: Fargetta Marco [mailto:marco.farge...@ct.infn.it] Sent: 13 March 2014 11:24 To: OpenStack Development Mailing List Subject: [openstack-dev] [swift] Replication multi cloud Hi all, we would use the replication mechanism in swift to replicate the data in two swift instances deployed in different clouds with different keystones and administrative domains. Is this possible with the current replication facilities or they should stay in the same cloud sharing the keystone? Cheers, Marco -- Eng. Marco Fargetta, PhD Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy EMail: marco.farge...@ct.infn.it ___ 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 ___ 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] [all][keystone] Increase of USER_ID length maximum from 64 to 255
Hi Morgan, On Tue, Feb 25, 2014 at 11:47:43AM -0800, Morgan Fainberg wrote: For purposes of supporting multiple backends for Identity (multiple LDAP, mix of LDAP and SQL, federation, etc) Keystone is planning to increase the maximum size of the USER_ID field from an upper limit of 64 to an upper limit of 255. This change would not impact any currently assigned USER_IDs (they would remain in the old simple UUID format), however, new USER_IDs would be increased to include the IDP identifier (e.g. USER_ID@@IDP_IDENTIFIER). in this case if a user would access with different systems (e.g. SAML with portal, LDAP with CLI) it is mapped to two different identities inside keystone. Is this correct? If so, is there any way to map an individual person with two identities sharing resources? Cheers, Marco There is the obvious concern that projects are utilizing (and storing) the user_id in a field that cannot accommodate the increased upper limit. Before this change is merged in, it is important for the Keystone team to understand if there are any places that would be overflowed by the increased size. The review that would implement this change in size is https:// review.openstack.org/#/c/74214 and is actively being worked on/reviewed. I have already spoken with the Nova team, and a single instance has been identified that would require a migration (that will have a fix proposed for the I3 timeline). If there are any other known locations that would have issues with an increased USER_ID size, or any concerns with this change to USER_ID format, please respond so that the issues/concerns can be addressed. Again, the plan is not to change current USER_IDs but that new ones could be up to 255 characters in length. Cheers, Morgan Fainberg — Morgan Fainberg Principal Software Engineer Core Developer, Keystone m...@metacloud.com ___ 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] 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
