[Freeipa-devel] Certificate Identity Mapping

[Jan Cholasta]

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.

>
>>
>>>
>>>>
>>>>>   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.

>
> 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