The LTER LDAP will be deprecated in Fall 2020 by the NCEAS LNO. As such, the EDI authentication service should no longer support LTER LDAP as an option for an authentication.

When setting up the log level, config.LEVEL is not referenced.

This ticket is to check how the log level is set up with daiquiri in our other projects, then implement the same for auth, and ensure that there is only one logical location in which the log level can be configured.

Currently, logging out only logs out the local session in PASTA. The user remains logged in, at the identity provider level.

Design and develop a user registry component that holds key attributes of a user (e.g., preferred email, nickname, group associations, identity mappings, notification preferences).

BNZ fails to authenticate due to server error:

2020-10-02 12:19:15,455 [1545] ERROR webapp.routes: Exception on /auth/login/pasta [GET]
Traceback (most recent call last):
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/site-packages/flask/app.py", line 2446, in wsgi_app
response = self.full_dispatch_request()
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/site-packages/flask/app.py", line 1951, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/site-packages/flask/app.py", line 1820, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/site-packages/flask/_compat.py", line 39, in reraise
raise value
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/site-packages/flask/app.py", line 1949, in full_dispatch_request
rv = self.dispatch_request()
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/site-packages/flask/app.py", line 1935, in dispatch_request
return self.view_functionsrule.endpoint
File "./webapp/routes.py", line 83, in login
credentials = base64.b64decode(authorization.strip('Basic ')).
File "/home/pasta/anaconda3/envs/auth/lib/python3.7/base64.py", line 87, in b64decode
return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

Auth creates multiple log file outputs from both the Python side and Gunicorn. To better manage these log files, we should:

1. Create a PASTA log directory in /var/log: /var/log/pasta
2. Have all log files write their respective output to the directory created in 1
3. Configure and use logrotate to rotate all log files found in the directory created in 1

Use the approach outlined here: https://medium.com/@elvis.gosselin/plantuml-for-database-modeling-1b71e6d4622d

The new diagrams should include only actions performed by auth and the IdP (interactions with the Gatekeeper and PASTA are excluded).

The login handler in routes.py uses matching rule /auth/login/<idp> and then runs separate blocks of code for each idP. Refactor this to use separate handlers for each IdP. E.g., for Microsoft, /auth/login/microsoft.

Update: Setting as 'wontfix' here, but creating a new ticket for it in the DataPortal. Also see final comment.

FastAPI follows different quoting and escaping rules than Flask, and determines that the PASTA token requires quoting when returned as a cookie. These quotes are allowed according to the RFC, but are not handled correctly by the Portal. We work around this by URL escaping the PASTA token before returning it as a cookie. The URL escaped token does not cause FastAPI to quote the token, and it is handled correctly in the Portal.

Some IdPs have a Cancel button in the login dialog. When clicked, the IdP redirects back to the app without providing the code query parameter. This scenario is currently unhandled in the auth service. When handled, the effect should be as if login was not attempted.

We are standardizing our web services on FastAPI.

For now, we'll be staying on Jinja2 for templating, and will try out HTMX for replacing (some?) of the JavaScript.

Add an identity mapping component that will allow a user authenticated with service A to be identified as the same user when they authenticate with service B.

Add a group management component that allows a individual to create a group and add other users to that group.

Update the production environment with security patches already applied in development.

On Wed, Nov 4, 2020 at 5:44 AM EDIorg [email protected] wrote:

Hello there!

On November 4th, 2020 at 12:44 (UTC) your application (EDI Authentication) used an access token (with the User-Agent python-requests/2.22.0) as part of a query parameter to access an endpoint through the GitHub API.

https://api.github.com/user

Please use the Authorization HTTP header instead as using the access_token query parameter is deprecated.

Depending on your API usage, we'll be sending you this email reminder on a monthly basis.

Visit https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param for more information about suggested workarounds and removal dates.

Thanks,
The GitHub Team

On Tue, May 10, 2022 at 6:53 PM sven bohm [email protected] wrote:

Hi Mark,

According to https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/authorizing-oauth-apps#oauth-app-access you can request read and/or write access. https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps appears to have a read:user scope to only read the user's email addresses. However, I have not had to implement this myself so I can't say what is involved.

If I understand it right, jollygoodcode/jollygoodcode.github.io#6 would like to have read-only access for the repo scope, which still does not exist apparently. However I don't think you would need to ask for repo access.

I verified that I have several third-party apps authorized with GitHub where the only right the integration has is to read my email addresses. For example

When converting the /auth/refresh API from Flask to FastAPI, the token parameter was mistakenly moved from the POST body to a query parameter. This ticket is to move it back to the expected location in the POST body.

User Stephani Schupbach reported an internal server error response when attempting to login into ezEML using his GitHub acccount.

On Fri, Oct 30, 2020 at 1:05 PM Schupbach, Stephani A [email protected] wrote:
I watched the EZEml video a few weeks ago and would like to try the tool. When I tried to login with my GitHub account, I received this error. Is the server really down or is it possible my DOI firewall is blocking my login?

Currently, clients provide a hostname as a target. auth then checks the hostname against lists of known hostnames and based on matches, wraps the target with different port, path and query parameters to create a complete URL for that client. The conditional logic involves a set of settings in auth, and splits the creation of the final target between the client and auth.

This ticket is to simplify things by removing make_target_url() and all the related settings from auth, and instead require clients to provide a complete URL as target. auth will still add some query parameters to this URL, but otherwise leave it unchanged.

Note that this additionally requires changes to all clients that use auth.

Microsoft and GitHub have an option to cancel a login in progress. When the user cancels the login, they should be brought back to the login page. Currently, this process is not handled, and causes an error in the auth service.

Recent changes to the Data Portal that perform authentication token refresh requests are now resulting in rate limiting of the Data Portal. All of the edirepository.org hosted servers should be added to a whitelist for rate limiting.

Add an endpoint for GET at /auth/ping which will return 200 if the service appears to be running.

Our Microsoft oauth app, should be created under a Microsoft account that can be verified by Microsoft. Without verification, users get a warning about unverified publisher, like in the following test:

This ticket includes planned fix for this issue in auth, and fix for downstream consequence in ezEML.

Starting May 1, a version of auth has been running which returns the user's Google sub (subject) identifier instead of the user's email address, for logins using Google as the IdP.

Modifications that we will do for auth:

• Change back to returning the email in the UID for Google (single one line change)
• Add another query parameter for the final redirect back to client, called 'sub' which will contain the user's Google sub identifier. This parameter will only be included for Google logins for now
• Add another column to the database called 'subject', in which we will store the 'sub' identifier. The column will be nullable and will only be filled in for Google logins for now

Modifications we will do for ezEML:

• When a user logs into ezEML, ezEML will generate a directory name based on the 'sub' and see if it exists.
• If it DOES NOT exist, ezEML will proceed as normal, using the email address for the directory name
• If it DOES exist, ezEML will:
  • Merge the JSON file in the sub based dir to the JSON file in the email based dir, with keys in sub overwriting those in email
  • Recursively copy the files in the sub dir over to the email dir, with files in sub overwriting those in email (take care to avoid copying the JSON file)
  • Move the sub dir over to a backup directory
  • Proceed as normal, using the email based dir