IQSS
Support for Shibboleth external users provided using Keycloak and integrated into the development environment
What this PR does / why we need it:
This PR enables the development environment to authenticate users via a Shibboleth Identity Provider (IdP) through Keycloak, and generate OIDC credentials for them to use within the single-page application (SPA). This addresses the following design that we defined a while ago for SAML-OIDC brokering:
This PR introduces a fully dockerized Shibboleth Identity Provider (IdP), backed by a dockerized LDAP directory containing test users. Keycloak has been configured to operate as a SAML Service Provider (SP) for the Shib IdP, enabling federated authentication flows within the development environment.
This setup provides a reusable boilerplate configuration that will serve as the foundation for integrating HarvardKey authentication in the beta Keycloak deployment. While additional ad-hoc configuration will be required to interoperate with InCommon in production, this PR lays the groundwork by including the necessary base setup.
Since this PR introduces new test flows that might raise some questions, I’ve recorded an informal demo to walk through the functionality and highlight a few key points. The focus is mainly on how it works in practice. We can go over the technical decisions and justifications at our next tech hours meeting.
https://github.com/user-attachments/assets/4e700593-2356-472e-843d-4e2775ff7314
The dev-env reverse proxy has been updated to use HTTPS. With these changes, all services are now exposed under https://localhost/, using a development SSL certificate. Using HTTPS was necessary to avoid incompatibilities with the new authentication flows, and applying it to all services has significantly simplified their configuration.
Below is a more detailed diagram, and more related to the implemented changes:
Which issue(s) this PR closes:
- Closes https://github.com/IQSS/dataverse/issues/11337
Special notes for your reviewer:
Initially, I created the PR in the backend repository, but later realized that adding Shib to the containerized environment is more relevant in the frontend repo, since that’s where we’ll be testing the end-to-end auth flows, including SPA + PKCE. However, if it becomes necessary to add Shib to the dataverse backend repo in the future, we can base it on what we have on the dataverse-frontend repo.
Suggestions on how to test this:
Follow the demo use cases.
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
N/A
Is there a release notes update needed for this change?:
N/A
coverage: 97.494% (+0.06%) from 97.432% when pulling 22ac93d4b6ff494a5d5ccd476125935cb5967778 on shib-idp-dev-env into 3a622afc8d34e8f0aa76ba24cd89c2c8f841c0dc on develop.
When I built this PR in local and hit login from the SPA - I'm not seeing the SAML option
hi @ofahimIQSS, please check the steps from the shib-dev-env folder README - Setup Instructions section.
Run the ./run-env.sh unstable command from inside the shib-dev-env folder also.
