On Fri, Mar 4, 2011 at 1:43 PM, Greg wrote:
> :) Okay, I stand corrected on the tests passing part; that was a jab though
> it did take a while to get there.
> I now back away from auth once again, as I have so many times before...
Well, it still wasn't a great branch.
If it had just been a plu
On Mar 4, 2011, at 1:25 PM, Jorge Williams wrote:
> I don't want this to deteriorate into a flame war but let's get our facts
> straight:
>
> 1) It completely integrated with the existing auth system and it integrated
> with our default Auth component.
> 2) All tests passed. I was looking o
On Mar 4, 2011, at 12:09 PM, Greg wrote:
> On Mar 4, 2011, at 11:05, Jorge Williams wrote:
>
>>
>> though we removed the details of this part at the request of the swift team.
>>Khaled implement this code to support both the default auth component
>> and to integrate the blueprint with
On Mar 4, 2011, at 11:05, Jorge Williams wrote:
>
> though we removed the details of this part at the request of the swift team.
> Khaled implement this code to support both the default auth component and
> to integrate the blueprint with swift. The response to our blueprint, from
> the
> But, unless I'm mistaken, there is only a single call to the auth
> server on the first request. If we go with a Swift model (which is
> similar to the proposed solution from Vish and Andy, but not quite the
> same), the auth server returns the storage-management-url after
> authenticating the us
> Good points above.
>
> Also good point :)
>
> Yup.
>
> Yes, you have a vote, and yes, it counts.
Thank you very much :)
> Would the best option be if the OpenStack API supported both auth
> mechanisms (signature, basic HTTP) and allowed the deployers to pick
> which ones were best for which
On Mar 4, 2011, at 10:29 AM, Jay Pipes wrote:
> Would the best option be if the OpenStack API supported both auth
> mechanisms (signature, basic HTTP) and allowed the deployers to pick
> which ones were best for which clients? For instance, if OpenStack
> supported both auth mechanisms simultaneo
On Thu, Mar 3, 2011 at 3:59 PM, Michael Mayo wrote:
> I was thinking more of a "sniff someone's traffic and perform those same
> requests again" sort of attack. But then again, I'm an iPhone guy and not a
> security expert :)
> In the end, I'm simply advocating that we reduce the number of HTTP r
On Thu, Mar 3, 2011 at 3:33 PM, Michael Mayo wrote:
> Here are my thoughts, as a client developer:
> 1. Hit auth server first for token, then hit compute and storage endpoints
> This is fairly simple, but there are a couple of problems with it:
> a. It's not very curl or browser friendly (you have
>> It depends. If you're in a busy area of a big city with 1 bar of EDGE
>> coverage on your phone, latency becomes your biggest connectivity issue. So
>> if you're only doing something with the API every 24 hours, auth could
>> reasonably be close to 50% of the time you stare in frustration c
On Mar 3, 2011, at 7:02 PM, Michael Mayo wrote:
>> The problem with this logic is that you are optimizing wrong. In a token
>> based auth system, the tokens are valid generally for a period of time (24
>> hours normally with Rackspace auth), and it is a best practice to cache
>> this. Saying
> The problem with this logic is that you are optimizing wrong. In a token
> based auth system, the tokens are valid generally for a period of time (24
> hours normally with Rackspace auth), and it is a best practice to cache this.
> Saying that you are reducing HTTP requests for 1 request tha
> This is assuming that the endpoint url does not change, and is going to be
> the same for all users. It could be that the, say swift url, that you get is
> not the same as what someone else gets, based on their account, service
> level, or even current IP (for directing folks to the 'nearest'
On Mar 3, 2011, at 5:45 PM, Chuck Thier wrote:
> The problem with this logic is that you are optimizing wrong. In a token
> based auth system, the tokens are valid generally for a period of time (24
> hours normally with Rackspace auth), and it is a best practice to cache this.
> Saying that
The problem with this logic is that you are optimizing wrong. In a token
based auth system, the tokens are valid generally for a period of time (24
hours normally with Rackspace auth), and it is a best practice to cache
this. Saying that you are reducing HTTP requests for 1 request that has to
ha
On 3/3/11 4:46 PM, Michael Mayo wrote:
On Thu, Mar 03, 2011 at 01:23:07PM -0800, Michael Mayo wrote:
We're also getting something else
with a token server though: service discovery (via service URL headers
returned with token). This can be important for auto-configuring apps
since you can simply
On Thu, Mar 03, 2011 at 02:46:13PM -0800, Michael Mayo wrote:
> >> This is true. An endpoint list is certainly necessary, but it would be
> >> great if I only needed to call that one time instead of every time an auth
> >> token expires.
> >
> > You would probably want to refresh the service li
> On Thu, Mar 03, 2011 at 01:23:07PM -0800, Michael Mayo wrote:
>>> We're also getting something else
>>> with a token server though: service discovery (via service URL headers
>>> returned with token). This can be important for auto-configuring apps
>>> since you can simply enter a auth URL and th
On Thu, Mar 03, 2011 at 01:23:07PM -0800, Michael Mayo wrote:
> > We're also getting something else
> > with a token server though: service discovery (via service URL headers
> > returned with token). This can be important for auto-configuring apps
> > since you can simply enter a auth URL and the
Speaking of the auth related stuff... For the multitenant bp we need to
add support for 'accounts', etc. I have a branch proposed for merge
that has that in it, plus basic admin api's for users/accounts
(projects) in nova. It also adds to the builtin auth so you can use an
account:username l
> I agree the token round-trip may not be the best for mobile apps,
> but they can at least be cached.
This is exactly what I'm doing for our iOS app :) It still would be better if
I didn't have to do it at all, though. Even
> We're also getting something else
> with a token server though: ser
I was thinking more of a "sniff someone's traffic and perform those same
requests again" sort of attack. But then again, I'm an iPhone guy and not a
security expert :)
In the end, I'm simply advocating that we reduce the number of HTTP requests
needed to get information or get things done. Ge
I think you're overestimating the security risk in issue 3. You're bank's
website uses HTTPS. In order to launch a successful man-in-the middle attack
against it you would have to compromise the certificate authority. Basic Auth
with HTTPS against a single endpoint is pretty darn secure and
Hi Mike,
On Thu, Mar 03, 2011 at 12:33:11PM -0800, Michael Mayo wrote:
>Here are my thoughts, as a client developer:
>1. Hit auth server first for token, then hit compute and storage endpoints
>2. Signed requests
>This is a little more painful from a development standpoint, but it'
Here are my thoughts, as a client developer:
1. Hit auth server first for token, then hit compute and storage endpoints
This is fairly simple, but there are a couple of problems with it:
a. It's not very curl or browser friendly (you have to curl the auth server
first and copy the token, which
I agree with Greg here. Signatures complicate life for our clients, they are
not browser friendly, and I'm not really convinced that we need them. If we are
going to have a default (and I think that we should) it should be dead simple
to integrate with. I would vote for basic auth with http
On Mar 2, 2011, at 8:30 PM, Jesse Andrews wrote:
> I would prefer a signature based approach as the default (as signatures
> limits replay attacks; tokens allow an eavesdropper to make arbitrary
> requests if they obtain a token).
On the other hand, signatures make simple things difficult, such
I agree that things should be pluggable, but OpenStack needs to have a default.
Users need to know that they can point OpenStack client applications at
OpenStack providers and it should work.
I would prefer a signature based approach as the default (as signatures limits
replay attacks; token
2011/3/2 Michael Barton :
> On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen wrote:
>> I'd like to just mention this blog post:
>>
>> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> tl;dr quote:
>>
>> If you stop reading now you only need to remember one thing:
>> SSL/TLS
On Wed, Mar 2, 2011 at 2:38 PM, Soren Hansen wrote:
> I'd like to just mention this blog post:
>
> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
> tl;dr quote:
>
> If you stop reading now you only need to remember one thing:
> SSL/TLS is not computationally expensive any
2011/3/2 Michael Barton :
> HMAC is sort of appealing for Swift, since it'd let people choose to
> use HTTP instead of HTTPS for data that's not sensitive.
I'd like to just mention this blog post:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
tl;dr quote:
If you stop rea
> a secure channel too, but if not attacks are less severe since they
> are limited to reply attacks only (the request and parameters are used
> as part of the signature). We can easily support both (and others),
> but we need to understand the needs and constraints of each.
HMAC is sort of appeal
We can certainly try your suggestions but I think the path of least resistance
is to support an existing authentication scheme. You're right in stating that
the semantics are extremely close to cookies. I'd note that http auth schemes
almost always work in the exact same way -- that is client
2011/3/2 Jorge Williams :
> 1) Weak support in HTTP client libraries.
a) This surprises me. I definitely remember using cookies with several
different http libraries.
b) There is *no* support for the current alternative, since it's
something that was made up for this particular purpose. If peopl
Soren,
Really good question about why we didn't use cookies. There are two problems
that I see with cookies.
1) Weak support in HTTP client libraries. HTTP libs tend to not handle them
at all or to not handle them correctly. In the Java world, for example,
java.net.* doesn't handle cookies
On Tue, Mar 01, 2011 at 10:02:37PM +0100, Soren Hansen wrote:
> 2011/3/1 Eric Day :
> > Well, hopefully with a shared, modular service, we can add a token
> > module that uses cookies instead. :)
>
> Sure :) I was just hoping to extract whatever wisdom might have been
> behind the decision to seem
2011/3/1 Eric Day :
> Well, hopefully with a shared, modular service, we can add a token
> module that uses cookies instead. :)
Sure :) I was just hoping to extract whatever wisdom might have been
behind the decision to seemingly reinvent the concept of cookies.
Perhaps there's some reason to avoi
Well, hopefully with a shared, modular service, we can add a token
module that uses cookies instead. :)
-Eric
On Tue, Mar 01, 2011 at 09:53:36PM +0100, Soren Hansen wrote:
> On a subject of authentication, I've always been puzzled why the token
> isn't just set as a standard http cookie?
>
> If
On 3/1/11 2:53 PM, Soren Hansen wrote:
On a subject of authentication, I've always been puzzled why the token
isn't just set as a standard http cookie?
If it were, it would be dead simple to render a bit of HTML and
interact with the API directly from a web server. The EC2 API can't do
this beca
On a subject of authentication, I've always been puzzled why the token
isn't just set as a standard http cookie?
If it were, it would be dead simple to render a bit of HTML and
interact with the API directly from a web server. The EC2 API can't do
this because of the rather complex signature mecha
On Tue, Mar 01, 2011 at 09:47:00PM +0100, Soren Hansen wrote:
> 2011/3/1 Eric Day :
> > Signature based auth such as EC2 should also always require
> > a secure channel too, but if not attacks are less severe since they
> > are limited to reply attacks only (the request and parameters are used
> >
2011/3/1 Eric Day :
> Signature based auth such as EC2 should also always require
> a secure channel too, but if not attacks are less severe since they
> are limited to reply attacks only (the request and parameters are used
> as part of the signature).
Just a note: The request also includes a tim
42 matches
Mail list logo
