Re: [Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
On 22.2.2017 11:28, Sumit Bose wrote: On Wed, Feb 22, 2017 at 10:02:24AM +0100, Petr Vobornik wrote: On 02/22/2017 12:43 AM, Fraser Tweedale wrote: On Tue, Feb 21, 2017 at 06:12:23PM +0100, Petr Vobornik wrote: On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote: Hi, related to the Certificate Identity Mapping feature, a new CLI will be needed to find all the users matching a given certificate. I propose to provide this as: ipa certmaptest --certificate --- 2 users matched --- Matched user login: test1 Matched user login: test2 Number of entries returned 2 Please provide any comments, suggestions on the CLI or the output. Thanks, Flo. Thanks Flo for sharing it. I don't like the command name. It is not self explanatory. It says it is testing something, it is not clear what and the actual result is users who match the map configuration or have the cert in their user's entry. Better would be: $ ipa certmap-match --certificate How about `ipa certmap-find-user ...'? Doesn't get more obvious than that, IMO. Was thinking about that as well but I think that the command might, in future, return also something else then user object, e.g. ID override. No, since the ID override is related to a user the user should be returned not the override. "user" in IPA means IPA user, so there will be a difference between IPA users and external users, which I think was Petr's point. I agree with him that certmap-find-user is not the right name for the command, because it suggests that it returns only IPA users. bye, Sumit Pasting user story to give context if somebody is not familiar with it: """ As a Security Officer, I want to present IdM Server with an Employee Smart Card certificate and list all Employees with a matching role account, so that I can validate the configuration is correct Note: In FreeIPA 4.4, user-find --certificate can already find users linked with a certificate blob Acceptance criteria: * I can perform the administrative task both via IdM Web UI and CLI * When asking IdM for the information, I should always receive the same list that would be matched in client authentication workflows (by SSSD) * The list of users should include both users linked via standard certificate blob and other generically mapped users """ -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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 -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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 -- 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
Re: [Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
On Wed, Feb 22, 2017 at 10:02:24AM +0100, Petr Vobornik wrote: > On 02/22/2017 12:43 AM, Fraser Tweedale wrote: > > On Tue, Feb 21, 2017 at 06:12:23PM +0100, Petr Vobornik wrote: > > > On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote: > > > > Hi, > > > > > > > > related to the Certificate Identity Mapping feature, a new CLI will be > > > > needed to find all the users matching a given certificate. > > > > > > > > I propose to provide this as: > > > > > > > > ipa certmaptest --certificate > > > > --- > > > > 2 users matched > > > > --- > > > > Matched user login: test1 > > > > Matched user login: test2 > > > > > > > > Number of entries returned 2 > > > > > > > > > > > > > > > > Please provide any comments, suggestions on the CLI or the output. > > > > Thanks, > > > > Flo. > > > > > > > > > > Thanks Flo for sharing it. > > > > > > I don't like the command name. It is not self explanatory. It says it is > > > testing something, it is not clear what and the actual result is users who > > > match the map configuration or have the cert in their user's entry. > > > > > > Better would be: > > > $ ipa certmap-match --certificate > > > > > How about `ipa certmap-find-user ...'? Doesn't get more obvious > > than that, IMO. > > Was thinking about that as well but I think that the command might, in > future, return also something else then user object, e.g. ID override. No, since the ID override is related to a user the user should be returned not the override. bye, Sumit > > > > > > > > > Pasting user story to give context if somebody is not familiar with it: > > > """ > > > As a Security Officer, I want to present IdM Server with an Employee Smart > > > Card certificate and list all Employees with a matching role account, so > > > that I can validate the configuration is correct > > > > > > Note: In FreeIPA 4.4, user-find --certificate can already find users > > > linked > > > with a certificate blob > > > > > > Acceptance criteria: > > > * I can perform the administrative task both via IdM Web UI and CLI > > > * When asking IdM for the information, I should always receive the same > > > list > > > that would be matched in client authentication workflows (by SSSD) > > > * The list of users should include both users linked via standard > > > certificate blob and other generically mapped users > > > """ > > > -- > > > Petr Vobornik > > > > > > Associate Manager, Engineering, Identity Management > > > Red Hat, Inc. > > > > > > -- > > > 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 > > > -- > Petr Vobornik > > Associate Manager, Engineering, Identity Management > Red Hat, Inc. > > -- > 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 -- 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
Re: [Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
On 02/22/2017 12:43 AM, Fraser Tweedale wrote: On Tue, Feb 21, 2017 at 06:12:23PM +0100, Petr Vobornik wrote: On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote: Hi, related to the Certificate Identity Mapping feature, a new CLI will be needed to find all the users matching a given certificate. I propose to provide this as: ipa certmaptest --certificate --- 2 users matched --- Matched user login: test1 Matched user login: test2 Number of entries returned 2 Please provide any comments, suggestions on the CLI or the output. Thanks, Flo. Thanks Flo for sharing it. I don't like the command name. It is not self explanatory. It says it is testing something, it is not clear what and the actual result is users who match the map configuration or have the cert in their user's entry. Better would be: $ ipa certmap-match --certificate How about `ipa certmap-find-user ...'? Doesn't get more obvious than that, IMO. Was thinking about that as well but I think that the command might, in future, return also something else then user object, e.g. ID override. Pasting user story to give context if somebody is not familiar with it: """ As a Security Officer, I want to present IdM Server with an Employee Smart Card certificate and list all Employees with a matching role account, so that I can validate the configuration is correct Note: In FreeIPA 4.4, user-find --certificate can already find users linked with a certificate blob Acceptance criteria: * I can perform the administrative task both via IdM Web UI and CLI * When asking IdM for the information, I should always receive the same list that would be matched in client authentication workflows (by SSSD) * The list of users should include both users linked via standard certificate blob and other generically mapped users """ -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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 -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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
Re: [Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
On Tue, Feb 21, 2017 at 06:12:23PM +0100, Petr Vobornik wrote: > On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote: > > Hi, > > > > related to the Certificate Identity Mapping feature, a new CLI will be > > needed to find all the users matching a given certificate. > > > > I propose to provide this as: > > > > ipa certmaptest --certificate > > --- > > 2 users matched > > --- > > Matched user login: test1 > > Matched user login: test2 > > > > Number of entries returned 2 > > > > > > > > Please provide any comments, suggestions on the CLI or the output. > > Thanks, > > Flo. > > > > Thanks Flo for sharing it. > > I don't like the command name. It is not self explanatory. It says it is > testing something, it is not clear what and the actual result is users who > match the map configuration or have the cert in their user's entry. > > Better would be: > $ ipa certmap-match --certificate > How about `ipa certmap-find-user ...'? Doesn't get more obvious than that, IMO. > > Pasting user story to give context if somebody is not familiar with it: > """ > As a Security Officer, I want to present IdM Server with an Employee Smart > Card certificate and list all Employees with a matching role account, so > that I can validate the configuration is correct > > Note: In FreeIPA 4.4, user-find --certificate can already find users linked > with a certificate blob > > Acceptance criteria: > * I can perform the administrative task both via IdM Web UI and CLI > * When asking IdM for the information, I should always receive the same list > that would be matched in client authentication workflows (by SSSD) > * The list of users should include both users linked via standard > certificate blob and other generically mapped users > """ > -- > Petr Vobornik > > Associate Manager, Engineering, Identity Management > Red Hat, Inc. > > -- > 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 -- 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
Re: [Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
On 02/21/2017 05:15 PM, Florence Blanc-Renaud wrote: Hi, related to the Certificate Identity Mapping feature, a new CLI will be needed to find all the users matching a given certificate. I propose to provide this as: ipa certmaptest --certificate --- 2 users matched --- Matched user login: test1 Matched user login: test2 Number of entries returned 2 Please provide any comments, suggestions on the CLI or the output. Thanks, Flo. Thanks Flo for sharing it. I don't like the command name. It is not self explanatory. It says it is testing something, it is not clear what and the actual result is users who match the map configuration or have the cert in their user's entry. Better would be: $ ipa certmap-match --certificate Pasting user story to give context if somebody is not familiar with it: """ As a Security Officer, I want to present IdM Server with an Employee Smart Card certificate and list all Employees with a matching role account, so that I can validate the configuration is correct Note: In FreeIPA 4.4, user-find --certificate can already find users linked with a certificate blob Acceptance criteria: * I can perform the administrative task both via IdM Web UI and CLI * When asking IdM for the information, I should always receive the same list that would be matched in client authentication workflows (by SSSD) * The list of users should include both users linked via standard certificate blob and other generically mapped users """ -- Petr Vobornik Associate Manager, Engineering, Identity Management Red Hat, Inc. -- 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
[Freeipa-devel] Certificate Identity Mapping - new API to retrieve matching users
Hi, related to the Certificate Identity Mapping feature, a new CLI will be needed to find all the users matching a given certificate. I propose to provide this as: ipa certmaptest --certificate --- 2 users matched --- Matched user login: test1 Matched user login: test2 Number of entries returned 2 Please provide any comments, suggestions on the CLI or the output. Thanks, Flo. -- 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
Re: [Freeipa-devel] Certificate Identity Mapping
On Wed, Jan 18, 2017 at 09:59:49AM +0100, David Kupka wrote: > Hello everyone! > I would like to bring your attention to just published PRs implementing > FreeIPA part of Certificate Identity Mapping feature [0]: > > - certmap plugin [1] by Flo > - WebUI for certmap plugin [3] by Pavel > - tests for certmap plugin [2] by me > > Also please think about names of the commands, parameters, entries and > attributes. We've figured them somehow but if you have any suggestion that > would improve the understanding please share. Hi, thank you for the patches. Just a general comment about an open question in the design. Honza suggested to use a priority instead of an issuer name to make sure that only specific rules are used for a given issuer. The latest mail in the thread about it is https://www.redhat.com/archives/freeipa-devel/2017-January/msg00229.html. Do you have any opinions here? I think it won't change much in your patches but we should find an agreement before e.g. the OID are registered. bye, Sumit > > Please review them thoroughly, thanks! > > [0] https://www.freeipa.org/page/V4/Certificate_Identity_Mapping > [1] https://github.com/freeipa/freeipa/pull/398 > [2] https://github.com/freeipa/freeipa/pull/399 > [3] https://github.com/freeipa/freeipa/pull/400 > > -- > David Kupka > > -- > 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 -- 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
[Freeipa-devel] Certificate Identity Mapping
Hello everyone! I would like to bring your attention to just published PRs implementing FreeIPA part of Certificate Identity Mapping feature [0]: - certmap plugin [1] by Flo - WebUI for certmap plugin [3] by Pavel - tests for certmap plugin [2] by me Also please think about names of the commands, parameters, entries and attributes. We've figured them somehow but if you have any suggestion that would improve the understanding please share. Please review them thoroughly, thanks! [0] https://www.freeipa.org/page/V4/Certificate_Identity_Mapping [1] https://github.com/freeipa/freeipa/pull/398 [2] https://github.com/freeipa/freeipa/pull/399 [3] https://github.com/freeipa/freeipa/pull/400 -- David Kupka -- 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
Re: [Freeipa-devel] Certificate Identity Mapping
On 6.1.2017 10:48, Sumit Bose wrote:
On Fri, Jan 06, 2017 at 08:40:31AM +0100, Jan Cholasta wrote:
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: . 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
wo
Re: [Freeipa-devel] Certificate Identity Mapping
On 12/16/2016 09:34 AM, Florence Blanc-Renaud wrote: On 12/06/2016 04:39 PM, 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! Flo. Hi, the design page for Certificate Identity Mapping [1] has been updated with a schema proposal and an example of configuration data. Please share your comments, concerns, suggestions before January 7, so that we can finalize the API and start the implementation. Thanks, Flo. [1] http://www.freeipa.org/page/V4/Certificate_Identity_Mapping Hi, thanks for all the comments provided so far. The design page [1] has been updated and I hope that it reflects the current state of discussions: - removed configuration options that did not seem useful - shortened the feature name to certmap-xx - added the notion of priority in the cert map rules As always, comments are welcome. Flo [1] http://www.freeipa.org/page/V4/Certificate_Identity_Mapping -- 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
Re: [Freeipa-devel] Certificate Identity Mapping
On Fri, Jan 06, 2017 at 08:40:31AM +0100, Jan Cholasta wrote:
> 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.
>
Re: [Freeipa-devel] Certificate Identity Mapping
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: . 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 SA
Re: [Freeipa-devel] Certificate Identity Mapping
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 th
Re: [Freeipa-devel] Certificate Identity Mapping
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.
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 de
Re: [Freeipa-devel] Certificate Identity Mapping
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 n
Re: [Freeipa-devel] Certificate Identity Mapping
On 16.12.2016 09:34, Florence Blanc-Renaud wrote: On 12/06/2016 04:39 PM, 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! Flo. Hi, the design page for Certificate Identity Mapping [1] has been updated with a schema proposal and an example of configuration data. Please share your comments, concerns, suggestions before January 7, so that we can finalize the API and start the implementation. Thanks, Flo. 1) I'm not fan of host-mod --certmapping-prompt-username. IMO it would be better to base this on group membership, which would allow automember to be used. A possible solution would be to introduce a CoS-based policy object, similar to pwpolicy, but for hosts: certmappolicy-mod [HOSTGROUP] --prompt-username=Boolean certmappolicy-add HOSTGROUP --prompt-username=Boolean certmappolicy-del HOSTGROUP HOSTGROUP can be ommited in certmappolicy-mod, in which case the default policy is modified. This would allow removing --prompt-username and --enable-local-prompt-policy from certmappingconfig. 2) Nitpick: could we please rename certmapping* to certmap*? Not only would it be quicker to type in the command line, but also named consistently with selinuxusermap. -- 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
Re: [Freeipa-devel] Certificate Identity Mapping
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 with only then name component (the part before the
Re: [Freeipa-devel] Certificate Identity Mapping
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: . 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 wou
Re: [Freeipa-devel] Certificate Identity Mapping
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
Re: [Freeipa-devel] Certificate Identity Mapping
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.
* 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?
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.
* 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 wou
Re: [Freeipa-devel] Certificate Identity Mapping
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.
* 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.
* 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. But as long as we keep the general mapping rule syntax
flexible the LDAP filter rules can be added in a later version.
* 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.
* nsslapd-certmap-basedn, see DOMAINDN abov
Re: [Freeipa-devel] Certificate Identity Mapping
On 12/06/2016 04:39 PM, 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! Flo. Hi, the design page for Certificate Identity Mapping [1] has been updated with a schema proposal and an example of configuration data. Please share your comments, concerns, suggestions before January 7, so that we can finalize the API and start the implementation. Thanks, Flo. [1] http://www.freeipa.org/page/V4/Certificate_Identity_Mapping -- 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
[Freeipa-devel] Certificate Identity Mapping
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! Flo. -- 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
