Repository navigation
Replies: 5 comments
|
Another Kerberos/PAC candidate, the "industry standard library for working with Kerberos/SPNEGO authentication in Java in 2023+" https://github.com/bedrin/kerb4j - same license LGPL-2.1. Clearly a descendant of the JaasLounge code. There is also some overlap with https://github.com/freeipa/ipa-tuura:
|
|
For the record: Keycloak 25.0.0 server requires OpenJDK 21 minimum (adapters remain compatible with Java 11 and Java 17) Keycloak release notes. |
|
For channel binding (RFC 5056) between HTTPS tunnel and GSSAPI context: hook into org.wildfly.security ? Browser support is unclear to me; but OS-level components and APIs support it. |
|
User should be able to opt-out from GSSAPI autologon (currently, if the user logs out from Keycloak security-admin-console or account-console, Keycloak will immediately re-login the user). And user should see the Negotiate endpoint under sign-ins (realms/REALM/account/account-security/signing-in). "Virtual hosting" problem: let's say we're reachable under idp.example.com, and obtain keytabs for ... how do we safely match keytab to GSSAPI context? |
|
Somewhat related: Also:
Looking forward for feedback. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I am reading code and brainstorming to update the LDAP federation provider to talk the full AD Forest protocol when locating users, and to add the newest Kerberos security mechanisms to the Kerberos federation provider.
The current LDAP federation uses heuristics to transform the Kerberos principal into a likely userPrincipalName to be foud in the configured LDAP server. Unfortunately this fails for domains with multiple UPNSuffixes (which is common with Microsoft Entra). It also ignores the altSecurityIdentities attributes which may hold alternate principal names.
These features require to read and validate the Kerberos PAC. Novadays, these carry a signature which should be authenticated. In turn, they hold enough user/profile information that a Kerberos federation could work entirely without LDAP.
The Kerberos PAC also contains attestation if MFA-had-happened and of client-secret-freshness, which I would want to "carry over" from the Kerberos PAC into the workflow to skip MFA prompts in Web workflows when appropriate.
Regarding channel binding: when Negotiate happens over HTTPS, a channel binding between the TLS channel and the GSSAPI context is possible, and desirable.
More specifically:
Maybe:
New dependency to parse Kerberos PAC
I've looked at various Java PAC parsing libraries and found org.codelibs.jcifs to have inherited most of older projects' code and to be currently the most stable and maintained. It is licensed under LGPL-2.1 which to my understanding is compatible with Keycloak.
I'm wondering if a dependency on a fileserver is worth it, or if I should copy the PAC parsing code into keycloak-kerberos-federation.
Maybe related
LDAP Federation: Keycloak should recognize RFC2307 primary group memberships (and primaryGroupID references)
All reactions