Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Edmund Rhudy (BLOOMBERG/ 120 PARK)]

I flubbed my description of what I had in mind - I was thinking of GitHub 
personal access tokens as a model, _not_ OAuth tokens. I believe the normal 
excuse is "inadequate caffeine".

From: dolph.math...@gmail.com 
Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from 
Horizon when using Federation

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) 
<erh...@bloomberg.net> wrote:

+1 on desiring OAuth-style tokens in Keystone.

OAuth 1.0a has been supported by keystone since the havana release, you just 
have to turn it on and use it:

  http://docs.openstack.org/developer/keystone/configuration.html#oauth1-1-0a 
-- 
-Dolph

__
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] Getting Auth Token from Horizon when using Federation

[Dolph Mathews]

On Thu, May 12, 2016 at 8:10 AM Edmund Rhudy (BLOOMBERG/ 120 PARK) <
erh...@bloomberg.net> wrote:

> +1 on desiring OAuth-style tokens in Keystone.
>

OAuth 1.0a has been supported by keystone since the havana release, you
just have to turn it on and use it:


http://docs.openstack.org/developer/keystone/configuration.html#oauth1-1-0a
-- 
-Dolph
__
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] Getting Auth Token from Horizon when using Federation

[Adam Young]

On 05/12/2016 09:07 AM, Edmund Rhudy (BLOOMBERG/ 120 PARK) wrote:
+1 on desiring OAuth-style tokens in Keystone. The use cases that come 
up here are people wanting to be able to execute jobs that use the 
APIs (Jenkins, Terraform, Vagrant, etc.) without having to save their 
personal credentials in plaintext somewhere, and also wanting to be 
able to associate credentials with a project instead of a specific 
person, so that if a person leaves or rotates their password it 
doesn't blow up their team's carefully crafted automation.
We can sort of work around it with LDAP service accounts as mentioned 
previously, but the concern around those is the lack of speedy 
revocability in the event of a compromise, and the service accounts 
could possibly be used to get to non-OpenStack places until they get 
shut down. One thought I had to try to keep the auth domain 
constrained to only OpenStack was using the EC2 API because at least 
that means you're not saving LDAP passwords on disk and the access 
keys are useless beyond that particular Keystone installation, but you 
run into impedance mismatches between the Nova API and AWS EC2 API, 
and we'd like people to use the native OpenStack APIs. (Turns out the 
notion of using AWS's EC2 API to talk to a private cloud is strange to 
people not steeped in cloudy things.)
So Service accounts and OAuth consumers are two different names for the 
same abstract construct. IN both cases, the important thing is limiting 
the access each one has.



Horizon is for the interactive use case, though, and should not be using 
either, except as a front to define workflows, and in that case, the 
same work should be possible from the command line.


ECP should make that possible, assuming your IdP supports ECP (EIEIO!).




From: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token 
from Horizon when using Federation


Hi Dolph, On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
> > On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert
<mar...@millnert.se <mailto:mar...@millnert.se>> > wrote: > Hi, >
> we're deploying Liberty (soon Mitaka) with heavy reliance on >
the SAML2 > Federation system by Keystone where we're a Service
Provider > (SP). > > The problem in this situation is getting a
token for direct > API > access.(*) > > There are conceptually two
methods to use the CLI: > 1) Modify ones (each customer -- in our
case O(100)) IdP to > add support > for a feature called ECP(**),
and then use keystoneauth with > SAML2 > plugin, > 2) Go to (for
example) "Access & Security / API Access / View > Credentials" in
Horizon, and check out a token from there. > > > With a default
configuration, this token would only last a short > period of
time, so this would be incredibly repetitive (and thus > tedious). 

Assuming all that is setup, the user should be unaware of the re-init to 
the SAML IdP to get a new assertion for a new token. Why is this a problem?




Indeed. > So, I assume you mean some sort of long-lived API
tokens? Right. > API tokens, including keystone's UUID, PKI, PKIZ,
and Fernet tokens > are all bearer tokens, so we force a short
lifetime by default, > because there are always multiple parties
capable of compromising the > integrity of a token. OAuth would be
a counter example, where OAuth > access tokens can (theoretically)
live forever. 



Still think that is a security violation.



This does sound very interesting. As long as the end user gets
something useful to plug into the openstack auth libraries/APIs,
we're home free (modulo security considerations, etc). > 2) isn't
implemented. 1) is a complete blocker for many > customers. > >
Are there any principal and fundamental reasons why 2 is not >
doable? > What I imagine needs to happen: > A) User is
authenticated (see *) in Horizon, > B) User uses said
authentication (token) to request another > token from > Keystone,
which is displayed under the "API Access" tab on > "Access & >
Security". > > > The (token) here could be an OAuth access token.
Will look into this (also as per our discussion in Austin). The
one issue that has appeared in our continued discussions at home,
is the contrast against "service user accounts", that seems a
relatively prevalent/common among deployers today, which basically
use username/password as the api key credentials, e.g. the authZ
of the issued token: If AdminNameless is Domain Admin in their
domain, won't their OAuth access token yield keystone tokens with
the same authZ as they otherwise have? My presumptive answer being
'yes', brought me to the realization that, if o

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Edmund Rhudy (BLOOMBERG/ 120 PARK)]

+1 on desiring OAuth-style tokens in Keystone. The use cases that come up here 
are people wanting to be able to execute jobs that use the APIs (Jenkins, 
Terraform, Vagrant, etc.) without having to save their personal credentials in 
plaintext somewhere, and also wanting to be able to associate credentials with 
a project instead of a specific person, so that if a person leaves or rotates 
their password it doesn't blow up their team's carefully crafted automation.

We can sort of work around it with LDAP service accounts as mentioned 
previously, but the concern around those is the lack of speedy revocability in 
the event of a compromise, and the service accounts could possibly be used to 
get to non-OpenStack places until they get shut down. One thought I had to try 
to keep the auth domain constrained to only OpenStack was using the EC2 API 
because at least that means you're not saving LDAP passwords on disk and the 
access keys are useless beyond that particular Keystone installation, but you 
run into impedance mismatches between the Nova API and AWS EC2 API, and we'd 
like people to use the native OpenStack APIs. (Turns out the notion of using 
AWS's EC2 API to talk to a private cloud is strange to people not steeped in 
cloudy things.)

From: openstack-dev@lists.openstack.org 
Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from 
Horizon when using Federation

Hi Dolph,

On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
> 
> On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <mar...@millnert.se>
> wrote:
> Hi,
> 
> we're deploying Liberty (soon Mitaka) with heavy reliance on
> the SAML2
> Federation system by Keystone where we're a Service Provider
> (SP).
> 
> The problem in this situation is getting a token for direct
> API
> access.(*)
> 
> There are conceptually two methods to use the CLI:
>  1) Modify ones (each customer -- in our case O(100)) IdP to
> add support
> for a feature called ECP(**), and then use keystoneauth with
> SAML2
> plugin,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
> 
> 
> With a default configuration, this token would only last a short
> period of time, so this would be incredibly repetitive (and thus
> tedious).

Indeed.

> So, I assume you mean some sort of long-lived API tokens?

Right.

> API tokens, including keystone's UUID, PKI, PKIZ, and Fernet tokens
> are all bearer tokens, so we force a short lifetime by default,
> because there are always multiple parties capable of compromising the
> integrity of a token. OAuth would be a counter example, where OAuth
> access tokens can (theoretically) live forever.

This does sound very interesting. As long as the end user gets something
useful to plug into the openstack auth libraries/APIs, we're home free
(modulo security considerations, etc).

> 2) isn't implemented. 1) is a complete blocker for many
> customers.
> 
> Are there any principal and fundamental reasons why 2 is not
> doable?
> What I imagine needs to happen:
>   A) User is authenticated (see *) in Horizon,
>   B) User uses said authentication (token) to request another
> token from
> Keystone, which is displayed under the "API Access" tab on
> "Access &
> Security".
> 
> 
> The (token) here could be an OAuth access token.

Will look into this (also as per our discussion in Austin).

The one issue that has appeared in our continued discussions at home, is
the contrast against "service user accounts", that seems a relatively
prevalent/common among deployers today, which basically use
username/password as the api key credentials, e.g. the authZ of the
issued token:

If AdminNameless is Domain Admin in their domain, won't their OAuth
access token yield keystone tokens with the same authZ as they otherwise
have?

My presumptive answer being 'yes', brought me to the realization that,
if one wants to avoid going the way of "service user accounts" but still
reduce authZ, one would like to be able to get OAuth access tokens for a
specific project, with a specific role (e.g. "user", or [project-]admin)
and the authZ this entails. This would keep the traceability, which is
one of the main issues with non-personal accounts.

How feasible is this last bit?


In general, the primary use case is:
 - I as a user of openstack on my personal computer retrieve a token to
manage openstack client operations without the need of storing my
Federation-username/password in local config (nor typing the password in
o

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Martin Millnert]

Hi Dolph,

On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
> 
> On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert 
> wrote:
> Hi,
> 
> we're deploying Liberty (soon Mitaka) with heavy reliance on
> the SAML2
> Federation system by Keystone where we're a Service Provider
> (SP).
> 
> The problem in this situation is getting a token for direct
> API
> access.(*)
> 
> There are conceptually two methods to use the CLI:
>  1) Modify ones (each customer -- in our case O(100)) IdP to
> add support
> for a feature called ECP(**), and then use keystoneauth with
> SAML2
> plugin,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
> 
> 
> With a default configuration, this token would only last a short
> period of time, so this would be incredibly repetitive (and thus
> tedious).

Indeed.

> So, I assume you mean some sort of long-lived API tokens?

Right.

> API tokens, including keystone's UUID, PKI, PKIZ, and Fernet tokens
> are all bearer tokens, so we force a short lifetime by default,
> because there are always multiple parties capable of compromising the
> integrity of a token. OAuth would be a counter example, where OAuth
> access tokens can (theoretically) live forever.

This does sound very interesting. As long as the end user gets something
useful to plug into the openstack auth libraries/APIs, we're home free
(modulo security considerations, etc).

> 2) isn't implemented. 1) is a complete blocker for many
> customers.
> 
> Are there any principal and fundamental reasons why 2 is not
> doable?
> What I imagine needs to happen:
>   A) User is authenticated (see *) in Horizon,
>   B) User uses said authentication (token) to request another
> token from
> Keystone, which is displayed under the "API Access" tab on
> "Access &
> Security".
> 
> 
> The (token) here could be an OAuth access token.

Will look into this (also as per our discussion in Austin).

The one issue that has appeared in our continued discussions at home, is
the contrast against "service user accounts", that seems a relatively
prevalent/common among deployers today, which basically use
username/password as the api key credentials, e.g. the authZ of the
issued token:

If AdminNameless is Domain Admin in their domain, won't their OAuth
access token yield keystone tokens with the same authZ as they otherwise
have?

My presumptive answer being 'yes', brought me to the realization that,
if one wants to avoid going the way of "service user accounts" but still
reduce authZ, one would like to be able to get OAuth access tokens for a
specific project, with a specific role (e.g. "user", or [project-]admin)
and the authZ this entails. This would keep the traceability, which is
one of the main issues with non-personal accounts.

How feasible is this last bit?


In general, the primary use case is:
 - I as a user of openstack on my personal computer retrieve a token to
manage openstack client operations without the need of storing my
Federation-username/password in local config (nor typing the password in
on the keyboard).

An extended use case definition of this being:
 - I as a user of openstack can provision an automated system with these
credentials, that can continue to operate as an openstack client for a
very long time without maintenance (i.e., either token renewal or
VeryLongLifetime).

Best,
Martin


__
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] Getting Auth Token from Horizon when using Federation

[Marco Fargetta]

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] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[John Dennis]

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?



--
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Adam Young]

On 04/18/2016 12:34 PM, Martin Millnert wrote:

Hi,

we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
Federation system by Keystone where we're a Service Provider (SP).

The problem in this situation is getting a token for direct API
access.(*)

There are conceptually two methods to use the CLI:
  1) Modify ones (each customer -- in our case O(100)) IdP to add support
for a feature called ECP(**), and then use keystoneauth with SAML2
plugin,
We have this working.  Your SAML provider might not.  What Are you 
working with?




  2) Go to (for example) "Access & Security / API Access / View
Credentials" in Horizon, and check out a token from there.

Insecure as all get out.  Please no.



2) isn't implemented. 1) is a complete blocker for many customers.

Are there any principal and fundamental reasons why 2 is not doable?
What I imagine needs to happen:
   A) User is authenticated (see *) in Horizon,
   B) User uses said authentication (token) to request another token from
Keystone, which is displayed under the "API Access" tab on "Access &
Security".

 From a general perspective, I can't see why this shouldn't work.


Let me explain.   A Token is a symmetric shared secret.  You should not 
be copyuing it around, etc.  You don't make it readable in a Web UI.  
You control it, and ideally, never let it see the light of day.




Whatever scoping the user currently has should be sufficient to check
out a similarly-or-lesser scoped token.

Anyway, we will, if this is at all doable, bolt this onto our local
deployment. I do, A) believe we're not alone with this use case (***),
B) look for input on doability.

We'll be around in Austin for discussion with Horizon/Keystone regarding
this if necessary.

Regards,
Martin Millnert

(* The reason this is a problem: With Federation, there are no local
users and passwords in the Keystone database. When authenticating to
Horizon in this setup, Keystone (I think) redirects the user to an HTTP
page on the home site's Identity Provider (IdP), which performs the
authentication. The IdP then signs a set of entitlements about this
identity, and sends these back to Keystone. Passwords stay at home. Epic
Win.)

(** 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.)

(***
https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
)


__
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] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Dolph Mathews]

On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert 
wrote:

> Hi,
>
> we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
> Federation system by Keystone where we're a Service Provider (SP).
>
> The problem in this situation is getting a token for direct API
> access.(*)
>
> There are conceptually two methods to use the CLI:
>  1) Modify ones (each customer -- in our case O(100)) IdP to add support
> for a feature called ECP(**), and then use keystoneauth with SAML2
> plugin,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
>

With a default configuration, this token would only last a short period of
time, so this would be incredibly repetitive (and thus tedious).

So, I assume you mean some sort of long-lived API tokens? API tokens,
including keystone's UUID, PKI, PKIZ, and Fernet tokens are all bearer
tokens, so we force a short lifetime by default, because there are always
multiple parties capable of compromising the integrity of a token. OAuth
would be a counter example, where OAuth access tokens can (theoretically)
live forever.


>
> 2) isn't implemented. 1) is a complete blocker for many customers.
>
> Are there any principal and fundamental reasons why 2 is not doable?
> What I imagine needs to happen:
>   A) User is authenticated (see *) in Horizon,
>   B) User uses said authentication (token) to request another token from
> Keystone, which is displayed under the "API Access" tab on "Access &
> Security".
>

The (token) here could be an OAuth access token.


>
> From a general perspective, I can't see why this shouldn't work.
>
> Whatever scoping the user currently has should be sufficient to check
> out a similarly-or-lesser scoped token.
>
> Anyway, we will, if this is at all doable, bolt this onto our local
> deployment. I do, A) believe we're not alone with this use case (***),
> B) look for input on doability.
>
> We'll be around in Austin for discussion with Horizon/Keystone regarding
> this if necessary.
>
> Regards,
> Martin Millnert
>
> (* The reason this is a problem: With Federation, there are no local
> users and passwords in the Keystone database. When authenticating to
> Horizon in this setup, Keystone (I think) redirects the user to an HTTP
> page on the home site's Identity Provider (IdP), which performs the
> authentication. The IdP then signs a set of entitlements about this
> identity, and sends these back to Keystone. Passwords stay at home. Epic
> Win.)
>
> (** 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.)
>
> (***
>
> https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
>
> https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
> )
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

[Martin Millnert]

Hi,

we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
Federation system by Keystone where we're a Service Provider (SP).

The problem in this situation is getting a token for direct API
access.(*)

There are conceptually two methods to use the CLI:
 1) Modify ones (each customer -- in our case O(100)) IdP to add support
for a feature called ECP(**), and then use keystoneauth with SAML2
plugin,
 2) Go to (for example) "Access & Security / API Access / View
Credentials" in Horizon, and check out a token from there.

2) isn't implemented. 1) is a complete blocker for many customers.

Are there any principal and fundamental reasons why 2 is not doable?
What I imagine needs to happen:
  A) User is authenticated (see *) in Horizon,
  B) User uses said authentication (token) to request another token from
Keystone, which is displayed under the "API Access" tab on "Access &
Security".

>From a general perspective, I can't see why this shouldn't work.

Whatever scoping the user currently has should be sufficient to check
out a similarly-or-lesser scoped token.

Anyway, we will, if this is at all doable, bolt this onto our local
deployment. I do, A) believe we're not alone with this use case (***),
B) look for input on doability.

We'll be around in Austin for discussion with Horizon/Keystone regarding
this if necessary.

Regards,
Martin Millnert

(* The reason this is a problem: With Federation, there are no local
users and passwords in the Keystone database. When authenticating to
Horizon in this setup, Keystone (I think) redirects the user to an HTTP
page on the home site's Identity Provider (IdP), which performs the
authentication. The IdP then signs a set of entitlements about this
identity, and sends these back to Keystone. Passwords stay at home. Epic
Win.)

(** 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.)

(*** 
https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
 
)


__
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