Skip to content

8 19 2024 Tech Team Report

Jump to bottom
qqmyers edited this page Aug 19, 2024 · 1 revision

8-19-2024

Logged Tasks

                            Date             Task Hours (Main) Hours (EOLS) Hours (PII) Hours (QDAS)
12-Aug-2024 Reporting, meeting, test forcing l2 from DV, investigate retrieving acr level from accessToken, try adding to user token, explore opt-in options 5
13-Aug-2024 Investigate getting acr from access token/combining with user info to decide whether l2 login is needed. 1
14-Aug-2024 Sitemap module update, explore getting acr in user token 1
15-Aug-2024 Update to use l2 only when admin, curator, or superuser, test 6
16-Aug-2024 Simple_sitemap and honeypot module updates, use new block for TKLabels on dev 1

Operations

SSO

  • Configured a level2/MFA step-up in Dataverse and confirmed user gets MFA request.
  • Added logic to query for user's role assignments and status. Any user with a curator or admin role for any collection, or any user who has superuser status will be forced to do a level2 authentication

Drupal

  • Sitemap, simple sitemap, honeypot module updates

Dataverse

  • As noted, started adapting the passive login filter to support requiring L2 auth only for privileged users (this is the new part).

HEAL

  • Coordinating re ~new issue connecting to stage. (Possibly due to the Keycloak version update.) Resolution TBD.

TKLabels

AnnoRep

Discussion

  • v6.3 deployment plan?
  • MFA - a frustrating aspect of the current MFA logic (deployed on dev) is that logging in from Dataverse first does a level1 login (the default, username/password) since the login is controlled by Drupal, and when the user is automatically redirected to Dataverse, the passive login checks their status and, if they are a curator/admin/superuser, they have to go through a level2 authentication immediately which repeats the password request and the asks for the one time token. So the overall effect logging in from Dataverse is having to login by password twice and then with the OTP. This is more natural if you login to Drupal and, some time later go to Dataverse where you get asked for password/OTP. It doesn't appear easy to avoid this now as we don't know which user is logging in until they enter their name in the Keycloak dialog to start the level1 authentication. I don't currently think there's a way to avoid re-entering the password by redefining the level2 login (i.e. I can't say level 2 means only enter the OTP), so the only possibility seems to be avoiding the initial level1 login. It may be possible to handle that by adding an attribute to users that need level2 (perhaps one flag that could cover both those above where it's required by policy and those that want to opt in). I'm not yet sure whether that can easily be included in the Keycloak dialogs and it may be better to deal with it like the email opt-in/changing your email - i.e. something you can indicate at sign-up and change later in Drupal. (Where required by policy, setting the flag to not do a level2 to start would just restore the double-password request above.) Any thoughts/ideas welcome. Another potential approach would be to somehow catch when users are doing something privileged, e.g. looking at a draft dataset or trying to edit. The challenge there is that many of those calls are in-page updates and redirecting to level2 auth would probably mean sending you back to the main dataset page (i.e. you're on a published dataset page /metadata tab and you hit edit - you'd go do the level2 and come back to the dataset page / main tab, not the edit metadata pane.) It might be possible in such an approach to make that more seamless, but probably more work and hard to guarantee that every privileged operation is caught. Could possibly be simpler in the SPA (where everything is an API call and perhaps all relevant PUT/POST calls could be annotated) and it may be possible to just respond with an error that level2 is needed, at which point the SPA would deal with request level2 and resending the call.

Plans

  • Get MFA to a usable state w.r.t. on authentication issue #43(MFA, etc.)
  • Shephard relationship type entry in metadata block #44 (more metadata to DataCite, etc.) through testing/review/QA
  • Background work to change/remove deprecated Drupal modules in prep for 11.0.0
  • Fix Stata-14 ingest by allowing file inspection during direct upload or adjusting the Stata ingester.
  • Fix #113 if possible
  • Matomo - investigate event-level tracking via tag manager, remove non-working google scripts
  • AnnoRep - explore round-trip, configure auto-start and log rotation
  • Ops
    • check missing globalidcreationdates and fix via /modifyRegistration or alternative
  • Dataverse
    • Make PR for guestbook adding datasetversion fix
    • Popup info accessibility - IQSS likes the recommendations from the source I linked to, so this can be implemented along those lines.
  • QDAS Previewer
    • Updates per request
    • Investigate writing aux file/previewing lower-sensitivity version and/or other write options
  • TBD: FRDR Security
Clone this wiki locally