[Freeipa-devel] Certificate Identity Mapping

[Jan Cholasta]

On 6.1.2017 10:48, Sumit Bose wrote:
> On Fri, Jan 06, 2017 at 08:40:31AM +0100, Jan Cholasta wrote:
>> On 5.1.2017 13:15, Sumit Bose wrote:
>>> On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote:
>>>> On 19.12.2016 12:13, 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.
>>>>>>>
>>>>>>> * --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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>>
>>>>>>> * 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.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> * 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.
>>>>
>>>> Right.
>>>>
>>>>>
>>>>> 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).
>>>>
>>>> I would personally prefer if we used Python-style formatting strings for the
>>>> templates, I find them much more pleasant to work with than C-style
>>>
>>> sure, I used %A etc as arbitrary templates, I didn't wanted to imply
>>> that C-style syntax should be used.
>>>
>>>> formatting strings. The filter which covers AD behavior could be written as:
>>>>
>>>>
>>>> (|(altSecurityIdentities=<I>{issuer_dn!x500}<S>{subject_dn!x500})(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.name}))
>>>
>>> I think this is quite readable and understandable to an admin with basic
>>> knowledge of LDAP search filters and certificate components. Are the
>>> names used here (issuer_dn, subject_dn, subject_nt_principal) already
>>> used by e.g. some Python modules or do we have to define the list of
>>> names?
>>
>> They are not defined anywhere, it's just something I came up with.
>>
>>>
>>> If there a reason for using '!x500' to indicate X500 ordering? Wouldn't
>>> e.g. issuer_dn.x500 work as well similar to Python's str.lower()? Having
>>> only one symbol to indicate a special formatting of the value from the
>>> certificate would make the syntax easier to learn.
>>
>> I tried to follow the Python convention, where '.' is used for attribute
>> access and '!' for value conversion. In other words, '.' selects a component
>> of the value and '!' takes the whole value and formats it in a certain way.
>
> ok, makes sense.
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>   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.
>>>>
>>>> This could be handled in the IPA plugin by converting from the user-friendly
>>>> representation to LDAP filter template internally when a mapping rule is
>>>> added or modified.
>>>
>>> Yes, but it can also be expanded by the component/library which will
>>> replace the templates with the actual values from the certificate. This
>>> would have the befit that the user-friendly representation is visible
>>> even with low-level LDAP commands?
>>
>> That's true (although I can't imagine why would anyone look on the LDAP
>> entries directly, especially if they didn't understand LDAP filters), but
>> IMHO it lacks certain elegancy by having more than one way to define the
>> same rule, more code paths to handle the rules, etc.
>>
>> Additionally, LDAP filters provide better forward compatiblity - if we had
>> to add support for a new mapping style in the future, with LDAP filters only
>> the IPA server would have to be updated, without LDAP filters we would also
>> have to worry about updating old clients which do not understand the new
>> mapping style.
>
> ok, but if the new mapping style introduces some new templates or
> formatting options the clients must be updated as well.

Right, the forward compatibility of LDAP filters is limited only to LDAP 
attribute names. When a new template or formatting option is added, the 
clients will have to be updated no matter which rule style we go with.

>
> bye,
> Sumit
>
>>
>>>
>>> bye,
>>> Sumit
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> * 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 at 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.
>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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
>>>>>>>
>>>>>>> * 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 at 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=sbose at 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?
>>>>>>
>>>>>> I think a better question is "How is userCertificate handled?"
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>> --
>>>> Jan Cholasta
>>
>>
>> --
>> Jan Cholasta


-- 
Jan Cholasta