On Sep 10, 2010, at 1:01 PM, Laurens Van Houtven wrote:
> Okay, to be specific: I believe the appropriate interface is IResource. This
> is in line with t.web's general way of interacting with cred: you give me
> credentials, I give you a protected IResource.
This doesn't quite make sense to me.
Mostly, I don't understand what the moving pieces are here. If this is all to
implement a "token endpoint" which doesn't "actually serve protected
resources", then what is the IResource being returned by the realm actually
*doing*? If it is not, itself, a "protected resource", then isn't the amount
of stuff that its IResource can do severely restricted (i.e. restricted to
doing a few OAuth-specific HTTP things) and therefore actually an avatar of a
completely different, OAuth-specific interface, which just happens to be
wrapped in an IResource by the OAuth implementation for the benefit of
formatting those OAuth-specific things over an HTTP channel?
Based on what you've said, I would expect the avatar interface to be 'IToken',
since the point of this authentication is to 'generate tokens'.
> It sounds like OAuth is very precisely implementing something that maps
> almost exactly onto the checker part of cred, but you're doing it by
> implementing a realm to allow applications to provide their own logic. This
> might not be the wrong idea, but it needs to be spelled out very clearly.
>
> Doing everything in the checker probably might make more sense. The reason I
> originally thought to do this in the IRealm is that I figured credentials
> checkers should just check credentials, and creating a new credential (the
> access token) wasn't part of ICredentialsChecker's job (more like IRealm's
> job). Apparently I was mistaken.
I'm going to handwave a bit here and pretend we're talking about a thing that
actually does serve arbitrary resources, so my answers may be slightly off.
But I think they may be applicable either way.
Speaking the authentication protocol is the authentication implementation's
job, not the realm or the checker. For example: if you need to generate a
challenge as part of the authentication process, the checker probably doesn't
need to get involved there. If you need to ask the checker something about the
challenge (let's say you have a list of persistent salts), then there needs to
be a method on the credential interface to allow the checker to relay that
information back.
It strikes me that creating a new access token is also an authentication
feature. If it is, then it goes into the OAuth resource somewhere. If it
needs to be pluggable then it needs to go into the ICredentialsChecker or
possibly the realm, but it's possible that this is just an OAuth specific
interface that is plugged in to the OAuth-doing IResource separately, as a
constructor argument that has nothing to do with cred.
> As you describe it:
>> token endpoints let you trade in some credentials that prove you're supposed
>> to have access for a token that actually *gives* you that access
>
> In cred-ese, that would be "checkers let you trade in some credentials that
> prove you're supposed to have access for an <avatar ID, which you give to a
> Realm> that actually *gives* you that access". As far as the OAuth response
> is concerned, it's like a checker. Looking at the individual parts, assuming
> that the avatar interface for the purposes of this discussion is IResource,
> it breaks down like this in my mind:
>> - the access token (an ascii string, mandatory)
>
> Avatar ID. (See, it's a str!)
>
> Heh, okay; as long as there's a plausible way to get the other important
> information (see rest of email) into the HTTP response, I'll believe you.
Yes. The way to get it into the HTTP response is: put it into the HTTP
response :). You don't necessarily need to cram it into the realm.
>> - the expiration time (optional)
> Implementation detail of the session. Avatars are actually sessions, which
> expire: sometimes (as with POP) at the end of a connection, sometimes (as
> with nevow.guard's HTTP support) with a session timeout.
>
> Right, but:
> a) The avatar needs to know about this timeout, since the timeout information
> needs to be able to make it into the HTTP response.
I'll stop you right there: No. (We can skip the rest of points b, c, and d,
since they all apparently follow from this.)
The avatar's job is to give you an IResource, but the OAuth implementation
doesn't necessarily need to pass through either the arguments to that resource
or that resource's return values (from getChild or render) exactly. If the
timeout needs to be put into the HTTP response as a header, the OAuth resource
could wrap the IResource value that it gets from the realm and set the header
before calling the ultimate resource's child.
Note that this isn't just the credentials checker: this is the OAuth
implementation. Relaying information there is easy though: depending on how
the checker itself gets created and parameterized, either you can have the
checker simply have a reference back to the OAuth resource so it can call some
methods, or you can expand the OAuth credentials interface to have a method
that the checker uses to pass that information back along with the resource.
>> - the refresh token (another ascii string, similar to the access token,
>> optional)
>
> Implementation detail of the authentication protocol. The client library and
> server library should be transparently refreshing this without telling either
> the client application code or server application code, right?
>
> Sure, but we're still writing library code here.
> If the avatar interface isn't actually IResource, but a new interface
> IAccessToken, getting the refresh token later might be feasible. (It should
> be a different interface, because in order to create a refresh token outside
> of this entire cred cycle, I need to know about the thing it's refreshing --
> so, the information in the response needs to be easily accessible and not
> just an opaque IResource).
>
> I agree entirely that clever client library code would abstract this mess
> away from application code. However, right now this code still needs to
> somehow be able to eventually produce HTTP responses that don't abstract
> anything yet and just contain all the appropriate data, because that's just
> what the OAuth spec says it needs to be able to do. There isn't any real
> application code in the token endpoint; they're pretty similar for all OAuth
> setups, and customization would typically happen through implementing the
> appropriate ICredentialsChecker.
Again: producing HTTP responses is not the same thing as producing IResource
implementations. You can have an HTTP response produced by an IResource that
wraps another IResource and adds some special sauce to the response. So this
information still never needs to make it to the realm.
>> - scope (an ascii string consisting of a set of space-separated words,
>> optional)
>
>
> This part doesn't quite fit, but could be expressed in one of two ways: a
> modification to the avatar ID, or as some extra structure on the Mind that
> modifies what functionality the Realm bundles in to your avatar
> implementation (without changing the interface provided by that object, of
> course).
>
> Unfortunately I don't believe this can be done through the mind. Again
> working under the previous assumption that ICredentialsChecker and not the
> IRealm is responsible for creating the access token, and scope is known to
> the thing that makes the access token, the ICredentialsChecker knows about
> the scope. Unfortunately the only way to pass stuff between the
> ICredentialsChecker and the IRealm is the avatar ID, so you don't have a
> choice.
OK, I admit it, by the time I get here I'm lost. We should try to meet up and
have an interactive conversation about this, because I have a ton of questions
about this, and I don't understand who generates the scope ID and why, and why
this bit of information would need to be relayed between the checker and the
realm in the process of authentication. Basically this goes back to the first
confusion I mentioned at the beginning of this email: I don't understand why
the realm is giving back an IResource if the whole purpose is to just generate
tokens and return them.
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
