[Freeipa-devel] Certificate Identity Mapping

[Florence Blanc-Renaud]

On 01/05/2017 01:30 PM, Sumit Bose wrote:
> 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.
>
Hi Summit,

glad you clarified your point because I clearly got it wrong :)
I will keep --prompt-username and I agree that there is no need for 
force-1-to-1-mapping.

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