Authentication, Authorization & Access Control

Authentication is finding out who you are dealing with. Authorization is if the authenticated user allowed to do what he does. Access Control is the implementation of it all. All of it together is sometimes called AAA.

You can configure basic AAA in app.yaml.

Authentication

gaetk2 uses Datastore Backed Credential Entities to handle Authentication. Clients can use

  • HTTP-Basic Auth (RfC 7617)
  • Session based Authentication via Forms
  • Google Appengine google.appengine.api.users.GetCurrentUser() Interface / Google Identity Platform
  • Auth0
  • HTTP-Bearer Auth (RfC 6750) with JSON Web Tokens (JWT, RfC 7519)

to provide authentication information. In addition gaetk2 can identifiy requests form certain infrastructure:

  • App Engine Task-Queues (X-AppEngine-QueueName)
  • Other App Engine Applications (X-Appengine-Inbound-Appid)
  • Sentry

To activate Authentication, just inherit from AuthenticationReaderMixin. E.g.:

class DefaultHandler(BasicHandler, AuthenticationReaderMixin):
    pass

Per default AuthenticationReaderMixin just decodes Authentication Information provided by the browser on its own. But to log in you have to make the user to authenticate himself. While gaetk2 can use username and password the main usage scenario is login via a third Party (Auth0 or Google). gaetk2 currently supports Google Identity Platform and Auth0 as login providers. Google because to use App Engine you and your colleagues already use Google Sign-In. Auth0 because it is well designed, powerful, easy to use and has decent debugging support.

LoginGoogleHandler and LoginAuth0Handler redirect the user to the OpenID Connect process where Google or Auth0 Make sure the user is who he claims. The user is then redirected back to GoogleOAuth2Callback or AuthOAuth2Callback where the information sent by Google or Auth0 is decoded, verified and on first time a Credential entity is created in the database.

Todo

  • Explain usage

Currently users are identified by their E-Mail Address. This might be problematic if a user changes his address but is the easiest way to identify the same user across different identity platforms.

For every authenticated user the uid (E-Mail) of the Credential is safed in the session. You can assume that when uid exists in the session the user is authenticated.

Configure Auth0

Create a new Client `at the Auth0 Dashboard <https://manage.auth0.com/`_. Should be “Regular Web Applications - Traditional web app (with refresh).”. Note the “Domain”, “Client ID” and “Client Secret” and put them into appengine_config.py:

GAETK2_AUTH0_DOMAIN='exam...ple.eu.auth0.com'
GAETK2_AUTH0_CLIENT_ID='QJ...um'
GAETK2_AUTH0_CLIENT_SECRET='mnttt-k0...supersecret'

Now you have to list all allowed URLs where your App may live - even for testing - in “Allowed Callback URLs”.

Authenticating Sentry

If you use Sentry for Log Aggregation and Error Reporting (See sentry-configuration.) then the Sentry Server will try to fetch certain resources like source maps from your App. Sentry uses a bilateral token to authenticate these calles. If you set GAETK2_SENTRY_SECURITY_TOKEN in appengine_config to the same value than in the Sentry Web Page Settings section all calls from the Sentry Sertver will be authenticated automatically with a uid of X-Sentry-Token@auth.gaetk2.23.nu.

Authorisation

Currently gaetk2 assumes each user which is authenticated is also authorized. Needs work.