Archivematica @ Wellcome Collection
  • Introduction
  • High-level design
  • Storing born-digital files
    • Creating a transfer package
    • Upload a transfer package to S3
    • Check a package was stored successfully
    • Downloading a package from the storage service
    • Following a package in the dashboard
  • Service architecture
    • How does Archivematica work?
      • The Archivematica apps
      • Microservices, tasks and jobs
      • Gearman, ElastiCache, and the MCP server/client
    • How is our deployment unusual?
      • What are our extra services?
      • ECS containers on EC2, not Fargate
      • Why we forked Archivematica
    • How it fits into the wider platform
  • About our deployment
    • Using Wellcome catalogue identifiers
    • Different environments
    • Working storage: MySQL, Redis, and EBS
  • Administering Archivematica
    • Bootstrapping a new Archivematica stack
    • User management
      • How to add or remove users
      • Authentication with Azure AD
    • Upgrading to a new version of Archivematica
    • Running an end-to-end test
    • Clearing old transfers from the dashboard
  • Debugging Archivematica
    • Where to find application logs
    • Troubleshooting known errors
      • Timeout waiting for network interface provisioning to complete
      • 401 Unauthorized when the s3_start_transfer Lambda tries to run
      • "pull access denied" when running containers (and other ECS agent issues)
      • "Unauthorized for url" when logging in
      • "gearman.errors.ExceededConnectionAttempts: Exceeded 1 connection attempt(s)" in MCP server
      • NotADirectoryError in the Extract zipped transfer stage
    • Restarting services if a task is stuck
    • SSH into the Archivematica container hosts
Powered by GitBook
On this page
  • How login looks for the user
  • How login works under the hood (roughly)
  1. Administering Archivematica
  2. User management

Authentication with Azure AD

PreviousHow to add or remove usersNextUpgrading to a new version of Archivematica

Last updated 2 years ago

Our Archivematica instance relies on Azure AD for user authentication.

How login looks for the user

Here's how the login flow works:

  1. A user goes to log in to Archivematica, and clicks the button that takes them to Azure AD:

    (Note: this screen is one of the changes in our Archivematica fork. We deliberately emphasise SSO over the username/password login.)

  2. This sends the user to the standard Wellcome AD login screen:

    The user logs in with their standard Wellcome username/password.

  3. The user gets redirected back to Archivematica, where they're now able to access the Archivematica dashboard.

How login works under the hood (roughly)

  1. A user goes to log in to Archivematica, and clicks the button that takes them to Azure AD.

  2. The user logs in to Azure AD with their standard username/password.

  3. If the login is successful, Azure AD sends a message to Archivematica telling it who this user is, e.g.

    This user is a.chan@wellcome.org.

    Azure AD will allow any user to "log in" to Archivematica this way. It doesn't enforce any permissions.

  4. Archivematica looks to see if it has a user with that email address. If so, it allows them to access the dashboard. If not, it rejects their login.

    This is how we control access to Archivematica -- only staff with a user configured in Archivematica will get past this step.