On Tue, Dec 20, 2016 at 10:10:29AM +0100, Florence Blanc-Renaud wrote: > Hi Sumit and Jan, > > thanks to both of you for providing detailed comments. Please find answers > inline. > > On 12/19/2016 12:13 PM, Sumit Bose wrote: > > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: > > > I agree with *almost* everything Sumit said. See my inline comments below. > > > > > > On 16.12.2016 11:53, Sumit Bose wrote: > > > > 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. > I saw this option as a convenient way to disable all the rules with a single > command, but I agree it's redundant with the mapping rules and we can live > without it. > > > > > > > > > * --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. > > > > > Agree, force-1-to-1-mapping is clearer.
Please don't get me wrong, I just wanted to point out that switching on and off the username prompt (or hint) is not the same as forcing a 1:1 mapping. I think it is good to have the --prompt-username option to tell applications which by default might not prompt for a user name when doing Smartcard authentication, like gdm or web apps, to show a user name. This allows to reach a similar behaviour as the 'username hint' GPO in AD. I think we currently do not have a requirement to force a 1:1 mappping. bye, Sumit > > > > > * --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. > OK, thanks for the heads-up. > > > > > > > > > * --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 > OK. > > > > > > > > > > > > > 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. > > > > > > LDAP ordering should indeed be preferred, as it is used everywhere else in > > > IPA. We can convert to/from X.500 ordering where necessary, when possible. > > > > We can use the issuerName attribute with LDAP ordering and convert when > needed, as Jan suggested. > > > > > > > > > * 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. > > > > > > We use domain names rather than DNs to refer to domains everywhere else in > > > the framework. I don't think this place should be an exception. > > > > I'm fine with domain names as well. In fact I didn't thought of using > > DNs for this before I read DOMAINDN on the design page. > > > I don't have any objection against using a domain name rather than a base > DN. > > > > > > > > > > > > * 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. > > > > > > I'm not sure I understand. Could you please elaborate a little bit? > > > > A LDAP search filter which would cover the AD behavior would look like: > > > > (|(altSecurityIdentities=<I>%A<S>%B)(userPrincipalName=%C)(samAccountName=%D)) > > > > where > > > > %A: must be replaced with the issuer of the certificate in X.500 order > > %B: must be replaced with the subject of the certificate in X.500 order > > > > it would be possible of course to use a specific template here which > > would generate the complete search attribute value. > > > > %C: must be replaced by the principal from AD's SAN > > szOID_NT_PRINCIPAL_NAME > > %D: must be replaced with only then name component (the part before the > > realm) of the principal from szOID_NT_PRINCIPAL_NAME > > > > As %C and %D imply this filter will only work for certificates which > > have szOID_NT_PRINCIPAL_NAME but for those it must be used to be > > compatible with AD. For certificates without > > > > (altSecurityIdentities=<I>%A<S>%B) > > > > is sufficient. It is possible to select the right filter with matching > > rules. > > > > So we have to find suitable names for the %A, %B, %C and %D templates > > and also allow different representations (e.g. LDAP or X.500 order for > > DNs). > > > > > > > > > But as long as we keep the general mapping rule syntax > > > > flexible the LDAP filter rules can be added in a later version. > > > > > > IMHO it should be the other way round and LDAP filters should be > > > implemented > > > first, as they offer all the flexibility we need (all of the other fields > > > can be easily implemented on top of LDAP filters) and are by default > > > extensible without having to update servers and clients. > > > > In general I agree, as long we can find a suitable scheme to handle the > > templates to add content from the certificate in a specific format to > > the search filters. > > > > But from the user/admin perspective there should be special rules for > > common use-cases which do not require to know too much details about > > certificates and LDAP trees. E.g. for AD (either via direct or indirect > > integration) there should be a <AD-LIKE> rule which just does all which > > AD would do depending on the certificate type. For IPA something like > > <ALT-SEC-ID-I-S> might be a good start for handling external > > certificates which do not contain user specific data which can be mapped > > to user object because the syntax is already known from AD. > > > > > > > > > > > > > * 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 > Agree, I prefer providing a single method to configure the user mapping. > > > > > > > > > * 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 > Agree. > > > > > > > > > * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I > > > > think both are note needed, see above > Agree. > > > > > > > > > * 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. > Agree. > > > > > > > > > * 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. > > > > > > I think it's worth mentioning that if the attribute used DN syntax and > > > matching, we wouldn't have to worry about normalizing the issuer name > > > before > > > searching for it, as DS would do that for us. > > > I agree with Jan, leveraging DN syntax would definitely be a pro, even if > the issuer DN is outside of the local tree. > If we use UTF-8 instead, would you apply format checks or also accept any > value non-DN conformant? > > > Good point, but I think the main use case for this attribute is on the > > client side to determine if a rule should be applied to a certificate or > > not. So I guess LDAP searches with this attribute would be rare because > > the client will load all rules in one run. > > > > > > > > > > > > > * nsslapd-certmap-basedn, see DOMAINDN above > OK for a domain instead of a DN, we could reuse associatedDomain instead. > > > > > > > > * 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 > OK. > > > > > > > > > * 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? > > > > > > I think a better question is "How is userCertificate handled?" > > > > There is already a self-service permission "Users can manage their own X509 > certificates". Same thing for OTP tokens, users are allowed to add a token > to their own account. > > Flo. > > > Anyway, self-service permissions can be enabled/disabled, so there is > > > really > > > no need for a new certmappingconfig option. > > > > Yes, this makes sense. > > > > bye, > > Sumit > > > > > > > > > > > That's all :-) > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > -- > > > Jan Cholasta > > > -- 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