authenticated_userid / unauthenticated_userid

[Christophe de Vienne]

Hi everyone,

We are implementing a IAuthenticationPolicy that requires, to get the
actual userid, an access to the database [1].

Should unauthenticated_userid always return None to avoid a database
access, or access the database to always return the same userid
authenticated_userid will return?

The documentation [2] is unclear about what matters most: "performs the
same duty as authenticated_userid", or "needn't (and shouldn't) check
any persistent store".

Thanks,

Christophe

[1] https://www.cubicweb.org/patch/4939057
[2]
http://pyramid.readthedocs.org/en/latest/api/interfaces.html#pyramid.interfaces.IAuthenticationPolicy.unauthenticated_userid

[Chris McDonough]

On 04/09/2015 04:09 AM, Christophe de Vienne wrote:
> Hi everyone,
>
> We are implementing a IAuthenticationPolicy that requires, to get the
> actual userid, an access to the database [1].
>
> Should unauthenticated_userid always return None to avoid a database
> access, or access the database to always return the same userid
> authenticated_userid will return?
>
> The documentation [2] is unclear about what matters most: "performs the
> same duty as authenticated_userid", or "needn't (and shouldn't) check
> any persistent store".

It should return the userid value sent in the request (usually in a
cookie) without checking if the userid is valid in any way.

- C

[Christophe de VIENNE]

Hello Chris,

Le jeudi 9 avril 2015 12:30:34 UTC+2, Chris McDonough a écrit :

On 04/09/2015 04:09 AM, Christophe de Vienne wrote:
> Hi everyone,
>
> We are implementing a IAuthenticationPolicy that requires, to get the
> actual userid, an access to the database [1].
>
> Should unauthenticated_userid always return None to avoid a database
> access, or access the database to always return the same userid
> authenticated_userid will return?
>
> The documentation [2] is unclear about what matters most: "performs the
> same duty as authenticated_userid", or "needn't (and shouldn't) check
> any persistent store".

It should return the userid value sent in the request (usually in a
cookie) without checking if the userid is valid in any way.

I understand that.

However the actual userid is not present in the request. Only a token that is associated to a user in the database.
Which means that getting an actual userid makes a database access mandatory.

Hence the question: should unauthenticated_userid returns an actual userid no matter what or let the actual job to authenticated_userid by returning None?

Christophe

[Chris McDonough]

Ideally, both methods should return the same kind of thing. If
unauthenticated_userid returns a token, so should authenticated_userid.

- C


>
> Christophe
>
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pylons-discus...@googlegroups.com
> <mailto:pylons-discus...@googlegroups.com>.
> To post to this group, send email to pylons-...@googlegroups.com
> <mailto:pylons-...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.

[Christophe de Vienne]

This token has no meaning outside this particular policy, and this
policy is inserted in a pyramid_multiauth stack.

So we must return the actual userid, and since both functions should
return the same thing, I feel we have to access the db in
unauthenticated_userid, although it is not meant to.

Unless of course if we consider that returning None in
unauthenticated_userid and an actual userid in authenticated_userid is
an acceptable behavior.

To summarize, the question is, which of these behavior is the least
acceptable?

- unauthenticated_userid returns None while authenticated_userid returns
something
- unauthenticated_userid access the database

My feeling is that accessing database is the lesser of two evil, but I
would like some confirmation.


Christophe

[Michael Merickel]

I've never had the assumption that unauthenticated_userid would return
the same thing as authenticated_userid. In my custom token-based
policy I simply have the former return the token and the latter checks
the database and converts it to a real user id.

The definition of a user id in pyramid is completely undefined minus
being convertible to a string.

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
> To post to this group, send email to pylons-...@googlegroups.com.

[Christophe de Vienne]

We did not do that for 2 reasons:

1) The documentation states "performs the same duty as
authenticated_userid". -> in my understanding, it means a value that is
usable as a principal and is no different from what authenticated_userid
would return, except the userid was not verified

2) This particular policy is one among others in our authentication
stack. Having it return something inconsistent with the other policies
feels wrong. It means that calling 'unauthenticated_userid' on the
top-level multiauth policy may return different things depending on the
policy that answered, even if the final userid is the same.

Am I wrong ?

[Mike Orr]

When would you use unauthenticated_userid, since it's insecure?

On Thu, Apr 9, 2015 at 6:49 AM, Christophe de Vienne

--
Mike Orr <slugg...@gmail.com>

[Christophe de Vienne]

I would not, but others may in ways I do not know about.

And since we are implementing a policy that others may use, I prefer it
to be well behaved.

So far I had no clear answer to my question, I hope someone can clarify
what is expected from unauthenticated_userid.

Cheers,

Christophe

[Chris Rossi]

The purpose of unauthenticated_userid is to produce something that can be passed to the callback used by most authentication policies to look up the user.  See the explanation of the 'callback' parameter on the various authentication policies that extend CallbackAuthenticationPolicy.  The 'userid' passed to the callback is from unauthenticated_userid.  The framework itself makes no use of unauthenticated_userid except in CallbackAuthenticationPolicy.  If you're not using an extension of CallbackAuthenticationPolicy, it should be safe to leave it unimplemented altogether.  Possibly, that method shouldn't be a part of IAuthenticationPolicy, but just be part of the implementation of CallbackAuthenticationPolicy.

The long and the short of it is, don't worry about it too hard.

Chris

[Jonathan Vanasco]

We use our own auth system, but have a similar setup.  Our "unauthenticated_userid" is a signed/encrypted http cookie value.   The "authenticated_userid" is a https session value (the token is signed/encrypted).

For a system that has low traffic or largely requires loggedin status (ie, social or applications), "unauthenticated" is not very useful.  However -- if you have heavy traffic that is largely read-only/public (ie, publishing) -- the overhead of loading and synching database backed sessions is noticeable and can become a bottleneck on your auth service.  A cheap way to handle customizing content, tracking user activity, and other non-security minded concerns is to use the unauthenticated_id in conjunction with a cached datastore.  That will eliminate needing to hit a database or auth-service on every request.

[Bert JW Regeer]

I’ve never been a fan of the whole authenticated_userid versus unauthenticated_userid. In all of my implementations of an auth policy that use a cookie with a token in it, I have unauthenticated_userid return None.

Even ones where it would be possible to retrieve a principal or userid, I still return None. From a security perspective, unauthenticated_userid might as well be a guest, and I use authenticated_userid as appropriate everywhere else in my code.

[Christophe de VIENNE]

Thanks everyone for the answers.

For now we decided that unauthenticated_userid would return None.

Christophe