Re: [Freeipa-devel] Certificate Identity Mapping

[Jan Cholasta]

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: . 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=%A%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 

[Freeipa-devel] [freeipa PR#209][synchronized] Enumerate available options in IPA installer

[Akasurde]

   URL: https://github.com/freeipa/freeipa/pull/209
Author: Akasurde
 Title: #209: Enumerate available options in IPA installer
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/209/head:pr209
git checkout pr209
From 92a641717c68d095997451df5eb74bb7dc2e5e77 Mon Sep 17 00:00:00 2001
From: Abhijeet Kasurde 
Date: Wed, 2 Nov 2016 16:36:17 +0530
Subject: [PATCH] Enumerate available options in IPA installer

Fix adds enumerated list of available options in IPA server
installer and IPA CA installer help options

Fixes https://fedorahosted.org/freeipa/ticket/5435

Signed-off-by: Abhijeet Kasurde 
---
 ipapython/install/cli.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ipapython/install/cli.py b/ipapython/install/cli.py
index b6f872e..4f2b0d5 100644
--- a/ipapython/install/cli.py
+++ b/ipapython/install/cli.py
@@ -179,6 +179,8 @@ def add_options(cls, parser, positional=False):
 elif issubclass(knob_scalar_type, enum.Enum):
 kwargs['type'] = 'choice'
 kwargs['choices'] = [i.value for i in knob_scalar_type]
+kwargs['metavar'] = "{{{0}}}".format(
+"|".join(kwargs['choices']))
 else:
 kwargs['nargs'] = 1
 kwargs['callback_args'] = (knob_scalar_type,)
-- 
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