Problem: Archivematica doesn't support OpenID Connect (OIDC) authentication

[helenst]

Please describe the problem you'd like to be solved
There is no support for authentication via Open ID Connect (as provided by Microsoft Azure platform and others). Doing so would enable users in organisations that use these platforms to log in with their existing accounts.

Describe the solution you'd like to see implemented
The solution could be similar to existing Shibboleth and LDAP auth implementations:

• enabled and configured from environment variables
• invisible on implementations where it is not required
• integrated with Django authentication system such that users can be automatically created
• implemented on both Archivematica and Storage Service web interfaces
• using existing libraries to provide the protocol implementations

Describe alternatives you've considered
There already are alternative ways to authenticate on Archivematica. This would provide an alternative method by which to do so.

Additional context
This has already been developed on the Wellcome fork.

---

For Artefactual use:

Before you close this issue, you must check off the following:

• All pull requests related to this issue are properly linked
• All pull requests related to this issue have been merged
• A testing plan for this issue has been implemented and passed (testing plan information should be included in the issue body or comments)
• Documentation regarding this issue has been written and merged
• Details about this issue have been added to the release notes

[sromkey]

@sevein Is this related to CAS at all?

[sevein]

It could be related, if CAS is set up with OIDC enabled (https://apereo.github.io/cas/5.1.x/planning/Architecture.html). Similarly, I believe that CAS can also be set up with SAML which Archivematica already supports (Shibboleth).

[sevein]

@alexwlchan we've just merged support for CAS and OIDC is next on the list and with the v1.12 milestone on it. Do you have some time to rebase artefactual/archivematica#1536, artefactual/archivematica-storage-service#517 and artefactual/archivematica-docs#342? Thanks!

[tw4l]

@sevein @alexwlchan It might be best to hold off rebasing the Storage Service PR until artefactual/archivematica-storage-service#538 is merged, which should happen in the next day or two. Thanks!

[alexwlchan]

I’ll keep an eye on Tessa’s storage service PR, and look at getting some time to rebase our OIDC PRs.

How soon is the v1.12 release?

[sromkey]

How soon is the v1.12 release?

We're aiming for August 28th, with a code freeze date of August 7th.

[tw4l]

@alexwlchan FYI, I just merged the CAS Storage Service PR into qa/0.x so you should be good to rebase now.

You might run into a known issue updating the Storage Service requirements in the Docker Compose dev environment. We're working a proper fix but for now there is a workaround described here: #1039 (comment).

[alexwlchan]

Do you have some time to rebase artefactual/archivematica#1536, artefactual/archivematica-storage-service#517 and artefactual/archivematica-docs#342?

Done, done and done!

[sevein]

Thank you!

[sevein]

@alexwlchan, I thought I would try this locally but I've stumped into something. I've set up testprovider which is what mozilla-django-oidc uses in their integration tests and I got pretty far with some changes I will describe below.

Added testprovider to Compose:

testprovider:
  stdin_open: true
  tty: true
  image: "mozilla/oidc-testprovider:oidc_testprovider-latest"
  ports:
    - "127.0.0.1:8080:8080"

These are the env strings I've added to archivematica-dashboard:

ARCHIVEMATICA_DASHBOARD_DASHBOARD_OIDC_AUTHENTICATION: "true"
OIDC_RP_CLIENT_ID: "1"
OIDC_RP_CLIENT_SECRET: "bd01adf93cfb"
OIDC_OP_AUTHORIZATION_ENDPOINT: "http://testprovider:8080/openid/authorize"
OIDC_OP_TOKEN_ENDPOINT: "http://testprovider:8080/openid/token"
OIDC_OP_USER_ENDPOINT: "http://testprovider:8080/openid/userinfo"

I had to make a change to the settings module (isn't it needed when using Azure?):

OIDC_AUTHENTICATION_CALLBACK_URL = "oidc_authentication_callback"

Also I updated the model in testprovider:

models.Client.objects.filter(pk=1).update(
    _redirect_uris="http://127.0.0.1:62080/oidc/callback/")

I am redirected to http://127.0.0.1:62080/oidc/callback/?code=... but JWS.from_compact(access_token) raises the following:

Compact JWS serialization should comprise of exactly 3 dot-separated components

Do you have any idea of what could be missing? Thank you in advance.

[alexwlchan]

Not sure off the top of my head; I’ll have a look at our config and send you the details tomorrow.

[alexwlchan]

@sevein I've had a look, and those two patches are very close to what we have in production (we just change the setting so Archivematica doesn't auto-create users when somebody logs in with OIDC – we create the AM user accounts manually and use people’s OIDC email as the account email).

These are the OIDC-related settings we're running in production:

AZURE_TENANT_ID = [uuid]
OIDC_RP_CLIENT_ID = [uuid]
OIDC_RP_CLIENT_SECRET = [secret]
OIDC_RP_SIGN_ALGO = RS256

The authorization/token/user endpoint are populated automatically, because we're running in Azure.

We don’t set the OIDC_AUTHENTICATION_CALLBACK_URL – I don't see where that setting is defined in the patch. Or is that a setting you'd expect to be defined somewhere?

Which docker-compose file are you using?

[sevein]

OIDC_AUTHENTICATION_CALLBACK_URL is part of mozilla-django-oidc, but I think that was just a problem specific to my configuration where Django didn't know what was its external URL and the one shared with the provider wasn't later recognized. I'm using the docker-compose file found in our development environment.

I will consult the team but I think we're ok to merge as is. I'll suggest to mark as experimental until we learn more.