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