jis-iam-bridge

Bridge Legacy IAM to JIS Cryptographic Identity

Keep your enterprise IAM. Add JIS on top. No rip-and-replace.

The Problem

Enterprises have millions of identities tied to centralized servers:

• Active Directory — Windows domain accounts, group policies
• LDAP — OpenLDAP, 389 Directory, cross-platform auth
• SAML — Federated SSO, Okta, Azure AD, PingFederate
• OAuth/OIDC — Google Workspace, Auth0, Keycloak

Every one of these systems is a middleman. Your identity exists because a server says it does. Server down? Identity gone. Breach? Everyone exposed.

JIS (Jasper Identity Scheme) uses cryptographic identity — no middleman. Your identity is derived from keys you control, verifiable by anyone, dependent on no central server.

But you can't migrate millions of users overnight. That takes years.

The Solution

jis-iam-bridge lets you keep your legacy IAM and add JIS on top. Every AD/LDAP/SAML/OAuth user gets a deterministic JIS identity derived from their existing credentials.

[Active Directory] ←→ [jis-iam-bridge] ←→ [JIS Identity]
[LDAP Server]      ←→ [jis-iam-bridge] ←→ [JIS Identity]
[SAML IdP]         ←→ [jis-iam-bridge] ←→ [JIS Identity]
[OAuth Provider]   ←→ [jis-iam-bridge] ←→ [JIS Identity]

How It Works

1. Register your IAM sources (AD domain, LDAP server, SAML IdP, OAuth provider)
2. Map users — each IAM user gets a deterministic jis: URI identity
3. Both systems work in parallel — legacy IAM for existing apps, JIS for new
4. Gradual migration — move workloads to JIS at your own pace
5. TIBET audit trail — every identity mapping is a provenance token

Identity Derivation

IAM user: "jvandemeent@corp.example.com" (Active Directory)
    ↓ deterministic hash
JIS identity: jis:a3f8c91b2d4e7063

The JIS identity is derived from the source type, domain, and user ID. Same input always produces the same JIS identity. No central registry needed.

Group Mapping

AD/LDAP groups are mapped to JIS capabilities:

AD Group "Domain Admins"    → JIS capability: admin
AD Group "Engineering"      → JIS capability: engineering
LDAP Group "cn=developers"  → JIS capability: developers

Installation

pip install jis-iam-bridge

CLI Usage

# Concept overview — the middleman problem and gradual migration
jis-iam-bridge info

# Demo — simulate 50 AD users, map to JIS, verify, show migration status
jis-iam-bridge demo

# Bridge statistics
jis-iam-bridge status

# Show configured IAM sources
jis-iam-bridge sources

Python API

from jis_iam_bridge import IAMBridge, IAMSource

bridge = IAMBridge()

# Register an Active Directory source
bridge.add_source(IAMSource(
    name="Corp AD",
    source_type="active_directory",
    endpoint="ldaps://dc01.corp.example.com",
    domain="corp.example.com",
))

# Map a user to JIS identity
mapping = bridge.map_identity("jvandemeent", "active_directory")
print(mapping.jis_id)       # jis:a3f8c91b2d4e7063
print(mapping.source_type)  # active_directory
print(mapping.active)       # True

# Resolve JIS identity back to IAM source
sources = bridge.resolve(mapping.jis_id)
print(sources[0].iam_user_id)  # jvandemeent

# Migration status per source
status = bridge.migration_status()
# {"active_directory": {"total": 500, "mapped": 123, "percentage": 24.6}}

TIBET Provenance

Every identity mapping creates a TIBET audit token:

• ERIN — the mapping action, IAM user, JIS identity
• ERAAN — IAM source, domain, groups
• EROMHEEN — bridge node, timestamp, sync context
• ERACHTER — intent description ("Identity bridge: AD → JIS")

License

MIT — Humotica / J. van de Meent

Credits

Designed by Jasper van de Meent. Built by Jasper and Root AI as part of HumoticaOS.

Stack-positie: Groep substrate · Bootstrap = OSAPI-handshake naar tibet + jis (fail → snaft-rule + tibet-pol-rapport) · ← jis-core · tibet-spiffe → · See STACK.md · See demo/golden-path/ for the spine end-to-end.

Enterprise

For private hub hosting, SLA support, custom integrations, or compliance guidance:

See ENTERPRISE.md for details.