On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: > Hi, > > I have started a feature description for the Certificate Identity Mapping at > the following location: > http://www.freeipa.org/page/V4/Certificate_Identity_Mapping > > This is a first step, focusing on the interface we would like to provide. It > still contains open questions, some of which are linked to the corresponding > design on SSSD side: > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities > > Comments, concerns and suggestions are welcome. Thanks!
Hi Flo, thank you very much for setting up the page. My comments are mostly about the commands. certmappingconfig-mod: * --enable=Boolean: if this option is 'False' SSSD will basically show the current behavior and just look up the certificates directly. But I wonder if the option is needed at all because not adding any mapping rules would have the same effect. What is the scope here, only the IPA domain, or all trusted domains as well? If it is for trusted domains as well will the certmappingrule-* commands and user-{add/remove}-certmapping return an error? So, in general I see an overlap with the mapping rules and I think it would be clearer to drop this option and do the lookups according to the mapping rules. * --prompt-username=Boolean: the description implies that this option is synonymous to 1:1 mapping, but it is not. On Linux authentication in most cases use a user name either by directly asking (e.g. /bin/login) or using the current user name (e.g. sudo). So, according to its name it would only control if gdm is allowed to ask for an (optional) user name. If the option is renamed to e.g. --force-1-to-1-mapping to really enforce a 1:1 mapping then it would make sense to derived to gdm behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to ask for a user name and if it is not enforced then it makes sense to offer and optional user name input field. * --enable-username-mismatch=Boolean: I think this option can be dropped. My test so far show that if a non-matching hint is given on a Windows client authentication fails. * --alternate-attribute=STRING: I think this option isn't needed as well. For IPA server-side we should decide on an attribute name and add it to the schema for user objects. On the client side the attribute name can be taken from the mapping rule.A certmappingrule.*: * ISSUERDN: it looks like you want to use issuerName here. In certificateRecord it it used with LDAP ordering and I would prefer LDAP ordering at all points where we have a choice. Unfortunately in the issuer-subject mapping AD dictates X.500 ordering. * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in the example? My intention in the SSSD design-page was to specify the domain (as in DNS domain/IPA domain/trusted domain) where the matching user should be searched. Different domains might certificates from different issuers and some domains might not even use certificates. With this information SSSD does not have to search any domain trusted by IPA from a given certificate, but look only at domains listed here (the attribute should be a multi-value one). There are objects in the LDAP tree for each trusted domain which are used by SSSD so using a DN syntax would be valid here. * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search filters should just be a special kind of mapping rules. I can image in syntax like: <LDAPFILTER:(&(cn=%A)(email=%B)(authType=pkinit))>. I think the difficult part with the LDAP filters will to define sensible templates. But as long as we keep the general mapping rule syntax flexible the LDAP filter rules can be added in a later version. * enable/disable: I think this is a good idea and would be consistent with other rules like HBAC and sudo * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be better to not add this option and only implement the 'user-{add/remove}-certmapping' commands * user-{add/remove}-certmapping: you say '... almost any type of mapping, or a more user-friendly API ...'. I would not say 'or' but 'and' and implement both * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I think both are note needed, see above * altSecurityIdentities: I would prefer to use a different name and OID. Using the same definition as AD would imo imply that it can be used in the same way as in AD. But e.g. AD also supports other content like KERBEROS:alternative_user_principal@AD.DOMAIN which we will not support. * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since the issuer DN in general will not be a DN from the local LDAP tree I think the UTF-8 version fits better. * nsslapd-certmap-basedn, see DOMAINDN above * altSecurityIdentities example: X.500 ordering is used by AD here and unfortunately I think we have to adopt it at least for this specific usage, here is an ldapsearch output from AD: altSecurityIdentities: X509:<I>DC=devel,DC=ad,CN=ad-AD-SERVER-CA<S>DC=devel,DC =ad,CN=Users,CN=t u,E=test.user@email.domain altSecurityIdentities: X509:<I>O=Red Hat,OU=prod,CN=Certificate Authority<S>DC =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sb...@redhat.co m,CN=Sumit Bose Sumit Bose * Certificate Mapping Administrators or re-use Certificate Administrators: I would prefer a new 'Certificate Mapping Administrators' * Users can manage their own X.509 certificate mappings? I'm not sure here, at the first glance I would say no. How are OTP tokens handled? Maybe this would be a candidate for certmappingconfig-* option? That's all :-) bye, Sumit -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code