One platform — standardized, built and operated by many.
One platform — standardized, built and operated by many.
As previously, our community engaged in the Gaia-x Hackathon #5 on September 26 – 27, 2022 with an own proposal. The goal of our track was to realize user federation at the infrastructure level with Keycloak via OpenID Connect.
Following the organizers’ recommendation, we joined forces with the team from walt.id, which in the end proved to be a great opportunity and resulted in an interesting use case. After aligning our proposals, we concluded to work together on realizing an SSI-based authentication with Gaia-X compliant Legal Person credentials for the IaaS layer of our reference implementation.
The first day of our joint hacking session was organized by the walt.id team which gave us a very good insight into SSI and their open-source technology, i.e. the walt.id SSI Kit, the walt.id Web Wallet and the walt.id IdP Kit. The following figure gives a good overview of how these components act together.
We created a self-signed Legal Person Credential via the walt.id SSI Kit and subsequently issued a Participant Credential through the Gaia-X Compliance API.
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/security/suites/ed25519-2020/v1",
"https://w3id.org/security/suites/jws-2020/v1"
],
"credentialSchema": {
"id": "https://raw.githubusercontent.com/walt-id/waltid-ssikit-vclib/master/src/test/resources/schemas/ParticipantCredential.json",
"type": "JsonSchemaValidator2018"
},
"credentialStatus": {
"id": "https://gaiax.europa.eu/status/participant-credential#392ac7f6-399a-437b-a268-4691ead8f176",
"type": "CredentialStatusList2020"
},
"credentialSubject": {
"ethereumAddress": "0x4C84a36fCDb7Bc750294A7f3B5ad5CA8F74C4A52",
"hasCountry": "GER",
"hasJurisdiction": "GER",
"hasLegallyBindingName": "deltaDAO AG",
"hasRegistrationNumber": "DEK1101R.HRB170364",
"hash": "9ecf754ffdad0c6de238f60728a90511780b2f7dbe2f0ea015115515f3f389cd",
"id": "did:web:wallet.walt-test.cloud:api:did-registry:2ede544a02964e2e83a0cbe0a0683bf6",
"leiCode": "391200FJBNU0YW987L26",
"parentOrganisation": "",
"subOrganisation": ""
},
"id": "urn:uuid:8d959928-d727-46b7-98af-b89c09b4cfb1",
"issued": "2022-09-26T10:15:50Z",
"issuer": "did:web:wallet.walt-test.cloud:api:did-registry:2ede544a02964e2e83a0cbe0a0683bf6",
"proof": {
"created": "2022-09-26T10:15:50Z",
"creator": "did:web:wallet.walt-test.cloud:api:did-registry:2ede544a02964e2e83a0cbe0a0683bf6",
"jws": "eyJiNjQiOmZhbHNlLCJjcml0IjpbImI2NCJdLCJhbGciOiJFZERTQSJ9..hMZNpUfax_Wu4PavK3kfYUI00JlqhOdZoWxuzO3dyWABeEFqdvLTkhJEq9nDskiYnYTIa6aWJID9q6yOGeVhDQ",
"proofPurpose": "assertionMethod",
"type": "JsonWebSignature2020",
"verificationMethod": "did:web:wallet.walt-test.cloud:api:did-registry:2ede544a02964e2e83a0cbe0a0683bf6"
},
"validFrom": "2022-09-26T10:15:50Z",
"issuanceDate": "2022-09-26T10:15:50Z",
"type": [
"VerifiableCredential",
"ParticipantCredential"
]
}
This VC will be used later to authenticate against our SCS testbed that we’ve prepared the week before.
The second day started with a very good discussion about user federation between multiple SCS-compliant cloud offerings. We identified three possible scenarios for Jane Doe:
This resulted in the following whiteboard that we sketched during brainstorming.
The rest of the day we spent on integrating the walt.id IdP into our Keycloak. Unfortunately we ran into an issue in Keycloak 19.0.1 which prevented us from setting the OIDC Identity Provider Client Authentication to Basic Authentication via the UI.
We decided to change the value clientAuthMethod via kcadm.sh and used the following trick
/opt/jboss/keycloak/bin/kcadm.sh get realms/osism > osism.json
sed -e 's/clientAuth_basic/client_secret_basic/' osism.json > osism2.json
/opt/jboss/keycloak/bin/kcadm.sh create partialImport -r osism -s ifResourceExists=OVERWRITE -o -f osism2.json
One of the great effects of such an event is that various people collaboratively work together on solving
issues. In a joint tmux-session we worked together and each of us was able to bring something to the table
to help succeed. While it might initially feel weird to “poke around together at the problem” in a shared
session, in the end it will lead to a good outcome as well as a learning experience for everyone.
Finally, we were able to use the Gaia-X compliant Participant Credential we’ve created earlier to authenticate against our Keycloak instance. 🎉
We identified several challenges that are still subject to further discussion.
Since we’re now starting into the R4 cycle and IAM and federation will be one of the items that will receive further shaping in R4 we will kick this off with a remote workshop on the overall IAM and federation subject on the 11th of october.
The two days of the Gaia-X Hackathon #5 were yet again very interesting and we had a lot of fun spending time together and hacking together. We especially thank the Gaia-X OSS Community for organizing this great opportunity and Phillip, Severin and Kai from walt.id for cooperating with us.
Many thanks also to our community members who participated in our session and contributed their knowledge. You are awesome! 🚀
Interested in continuing working on user federation? We still have some open challenges to tackle and we invite you to join our open community. Check out our public calendar and participate in our various team meetings.