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.
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
> >
> > * 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.
>
> 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@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?
>
> 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
--
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
