Skip to main content

TideCloak 0.10.2

This is a BIG release. I mean REALLY big. Just how big? Yeah... Exactly! We pretty much refactored the entire project tree structure to make it easier to carve out the IGA in a way that can be contributed back to the Keycloak project without any dependency on Tide. This release also includes other BIG enhancements and changes to increase security, improve DX and tremendously uplift performance.

Highlights:

  • IdP-less TideCloak IGA
  • Tide Delegated Auth Token - Doken
  • Simplified refactored JS SDK

Try our new, improved TideCloak dev Playground demo here:

Open in Codespaces

TideCloak changes​

Keycloak-IGA - Standalone FOSS IGA​

As part of the effort to split the TideCloak project to two, the tidecloak-admin-ui repo was relocated to keycloak-IGA that was relicensed under Apache 2.0 and released as a public open source project. This project offers all the new capabilities that aren't dependant on Tide Ineffable Cryptography or its services, while TideCloak continues, while sharing a mutual code-base. This new open-source project carves out Tide IdP but maintains Tide's Quorum-Enforced Authorization capabilities without TideCloak's cryptographic guarantee, making it a formidable Identity Governance and Administration layer to Keycloak.

All the users in a keycloak's realm that are assigned a realm-admin role, become a participant administrator in the quorum that is required to approve all draft changes to users, roles, composite roles, role mappings and clients. Administrators can review, approve, commit, reject and cancel drafts as designed for TideCloak's Quorum-Enforced Authorization, only by process (without the cryptographic enforcement).

This project includes a dedicated build script aligned with keycloak version 26.2.5, and detailed instructions on how to instantiate a server.

The Keycloak-IGA project is desigend to be contributed back to the Keycloak main project, with plans to eventually absorbed as mainstream inclusion.

IGA activity bundling support​

TideCloak's Quorum-Enforced-Authorization (IGA) progressed closer to support bulk operations, allowing admins to select mutiple drafts in a single approval or commit operation.

Tide Fabric multi model request​

Interface between TideCloak to Tide's Fabric has now been extended to support more than the single access token signing model. Models now are enumerated and requests to action a model is now abstracted. A "model" in Tide Fabric's context means an ineffable cryptographic operation that happens in zero-knowledge by a swarm of nodes in Tide's network without any of the nodes being able to compromise the execution of the model or leak its secrets.

Example models currently available are: OAuth access token, IDToken, Refresh token, Tide Doken (See below), Cardano transaction, etc.

Enhanced Enclave origins definition for better security​

Previous ability to define a single approved web origin for the Tide Secure Web Enclave (for log-in, or approval screen for example) has now been expanded to allow a list of approved origins.

SDK changes​

Simplified support for Javascript frameworks​

This release includes an overhaul to TideCloak's official Javascript SDK, breaking the previous developer package to 3 separate frontend frameworks, and one backend package:

References and guides can be found in Tide SDK documentation.

Revamped Tide Heimdall module​

Tide's developer's front-end plugin to invoke Tide's end-user capabilities, Tide's Heimdall, has been redesigned and published as a typescript module with greater performance, usability and security. This improved implementation is extremely lightweight and easy to use, that invokes all of Tide's client side cryptography in a separate, secure web enclave, either as an interactive user window, or a hidden web component.

The highlight of this release includes the segregation of the encryption/decryption functions to a secure browser enclave, tightening the security even further.

Cybersecurity Fabric changes​

Introducing the Tide Doken​

The Tide Delegated Authorization Token, the Doken, represents a leap in the Tide Protocol security, allowing one Tide user (Ineffable key) to grant a session-specific authorization to another user, to be used any time during that session. The way the Doken is being used in TideCloak is as follows:

  1. A Tide user blind-authenticates to TideCloak using their Consumer-Master-Key (CMK). The blind authenticated request includes that user's ephemeral session public key.
  2. TideCloak uses that user's blind-authentication as an IdP authentication and request the necessary tokens to be signed by its ineffable Verifiable Vendor Key (VVK).
  3. Tide's VVK signs all requested tokens (ID Token, Access token and Refresh token) for that user to use in the standard OAuth scenario.
  4. In addition, the Tide's VVK also signs a Doken, allowing the owner of the session key future access to request the VVK to perform specific Ineffable actions, like decryption or transaction signing (depending on the model).
  5. The user uses the OAuth tokens as required by the stadard flow.
  6. When accessing sensitive encryption informaiton, that user can now make requests directly to the VVK nodes to perform Ineffable Decryption.

This capability allows hermetic segregation between the user and the TideCloak IAM when it comes to making requests directly from the VVK nodes - guaranteeing sepearation of responsibilities and removal of attack vectors. It enforces an mTLS-like secure tunnel between the authenticated user to the Tide Fabric that is not exposed to DNS / CA threats.

It's important to note that all requests to the Fabric's nodes are accompanied by verifiable attestations pre-approved by the administration quorum.

Improved access token security​

A new mechanism in the Fabric now provide more granular controls around the dynamic content of the Access Token JWT, preventing a rogue TideCloak instance from adding unfamiliar permissions as part of the free-form additions.