On 7/16/24 12:30, Alexander Bokovoy wrote:
On Аўт, 16 ліп 2024, Christopher Byrne wrote:
Yeah, I know its deprecated, and since I doubt we have any users (yet) of it in Gentoo I dropped support for the old tool, and will only document the new one.
Basically, for passkey support, I need a schema that looks like this:
attributeTypes: ( passkey-oid NAME 'passkey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectclasses: ( passkeyUser-oid NAME 'passkeyUser' DESC 'Passkey user' AUXILIARY MAY passkey )
The "passKey user" objectClass can be added as an auxiliary class to the appropriate DN, which has the "passkey" member in the format SSSD expects. ("passkey":CredentialID,PEM)
Short of borrowing the IDP schema for passkeys, I don't see a good way of doing this. I don;t think either the FIDO2 or Yubico one will work for what SSSD is expecting.
I think you can take FreeIPA schema which is essentially the same, just that we have these OIDs already registered in Red Hat's subtree.
attributeTypes: ( 2.16.840.1.113730.3.8.23.27 NAME 'ipapasskey' DESC 'Passkey mapping' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.10' ) objectclasses: ( 2.16.840.1.113730.3.8.24.9 NAME 'ipaPasskeyUser' DESC 'IPA passkey user' AUXILIARY MAY ipapasskey X-ORIGIN 'IPA v4.10')
What specific IdP software are you talking about?
I am planning to add support for retrieving the mapping to Keycloak eventually. The content is compatible with what a typical WebAuthn RP is expecting, just needs some data massaging. For FreeIPA we also plan to use python-fido2 for WebAuthn RP, which is developed by Yubico, I already verified it will be possible to consume the data from the same mappings there.
I meant IPA, not IDP. I'll go ahead and use that piece of the FreeIPA schema instead and point SSSD to the correct attribute.