Re: [Freeipa-devel] Stageuser API
On ti, 17 tammi 2017, Christian Heimes wrote: On 2017-01-17 12:56, David Kupka wrote: Hi Christian, uniqueness of uid is not checked in staging area on purpose, it may be changed multiple times before the stageuser is transformed into user (activated). The uid uniqueness is then checked during activation. Third party application that use FreeIPA's LDAP should: 1) search for users (and usercertificate attribute) only in cn=users,cn=accounts 2) respect the value of nsAccountLock that is set to true for all staged users. But it would be nice to have this scenario (stageuser.uid == user.uid) implemented as a part of [1]. Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd party application *always* use the FreeIPA API or LDAP to validate a user cert? Some applications may just validate the certificate and OCSP/CRL for client cert authentication with e.g. mod_ssl. Consider this scenario: 1) IT issues a smart card for a staging user. The smart card contains a valid private/public key pair for FreeIPA. 2) HR sends the smart card to a new hire. 3) HR creates a standard user with same login as staging user 4) New hire uses the smart card to log into a system that only verifies validity of cert (signature, dates, OCSP status) and uses subject to identify user. The certificate validity for a future users should have validity.notBefore property set. A login before that time should not be possible with systems like (4) describes. Even if we 'fix' the issue with non-unique UIDs in staging, it stays dangerous to hand a valid certificate to a not-yet-valid user. At least we should try to reduce risks with a couple of measures: * Add a "valid from" field to stage users and set the cert's valid from date accordingly. That renders the public key useless until the estimated first day on the job. According to RFC 3280, validity is the mandatory part of the x.509 certificate. Granted, certmonger does not allow you to set validity.notBefore to some externally defined value, but this is something we could implement. You can already achieve that with your own certificate signing request. And it this case we deal with externally provided user certificates, so we could have no ability to influence what happens at all. * Lock the smart card with a PIN and don't release the PIN until the user has been moved from staging area to user area. This arrangement makes the smart card inaccessible. We could use the KRA to store the PIN. This is just a process, not a technical solution. Someone needs to communicate PIN separate to the smartcard to a new hire anyway. -- / Alexander Bokovoy -- 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] Stageuser API
On 2017-01-17 12:56, David Kupka wrote: > Hi Christian, > uniqueness of uid is not checked in staging area on purpose, it may be > changed multiple times before the stageuser is transformed into user > (activated). The uid uniqueness is then checked during activation. > > Third party application that use FreeIPA's LDAP should: > 1) search for users (and usercertificate attribute) only in > cn=users,cn=accounts > 2) respect the value of nsAccountLock that is set to true for all staged > users. > > But it would be nice to have this scenario (stageuser.uid == user.uid) > implemented as a part of [1]. Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd party application *always* use the FreeIPA API or LDAP to validate a user cert? Some applications may just validate the certificate and OCSP/CRL for client cert authentication with e.g. mod_ssl. Consider this scenario: 1) IT issues a smart card for a staging user. The smart card contains a valid private/public key pair for FreeIPA. 2) HR sends the smart card to a new hire. 3) HR creates a standard user with same login as staging user 4) New hire uses the smart card to log into a system that only verifies validity of cert (signature, dates, OCSP status) and uses subject to identify user. Even if we 'fix' the issue with non-unique UIDs in staging, it stays dangerous to hand a valid certificate to a not-yet-valid user. At least we should try to reduce risks with a couple of measures: * Add a "valid from" field to stage users and set the cert's valid from date accordingly. That renders the public key useless until the estimated first day on the job. * Lock the smart card with a PIN and don't release the PIN until the user has been moved from staging area to user area. This arrangement makes the smart card inaccessible. We could use the KRA to store the PIN. Christian signature.asc Description: OpenPGP digital signature -- 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] Stageuser API
On ti, 17 tammi 2017, Martin Basti wrote:
On 17.01.2017 12:38, Christian Heimes wrote:
On 2017-01-16 15:52, David Kupka wrote:
Hello everyone!
I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.
I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:
1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.
Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.
Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?
I see one potential issue in your proposal. A stage user does not
reserve its user name. The unique index on uid excludes the staging user
and deleted user branch. Therefore it is possible to create a user with
the same login name as a staging user.
We either have to ensure that this name clash does not cause any trouble
with certificates or we have to enforce uniqueness of uid across the
whole tree. For FreeIPA it's probably fine because we compare certs
bytes. Third party applications parse the cert subject instead and use
the subject to identify a user.
Christian
AFAIK the non-uniques of stageuser and user names causes more pain
than gain, this is not the first case when we have an issue with that.
Maybe we should reevaluate this behavior and enforce uid uniqueness
with stageusers too.
Note: we explicitly updated uniqueness plugin to allow conflicting
names but I don't remember the reason from top of my head.
There might be workflows where an existing normal user would be deleted
and a new but completely separate stageuser would be promoted to a
normal one, both having the same name over an overlapping period of time.
In this case non-uniqueness requirement is needed.
This is a fairly common situation for English-speaking countries with
rather short common surnames and a typical username built out of a
first name + surname combination.
--
/ Alexander Bokovoy
--
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] Stageuser API
On 17/01/17 12:38, Christian Heimes wrote:
On 2017-01-16 15:52, David Kupka wrote:
Hello everyone!
I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.
I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:
1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.
Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.
Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?
I see one potential issue in your proposal. A stage user does not
reserve its user name. The unique index on uid excludes the staging user
and deleted user branch. Therefore it is possible to create a user with
the same login name as a staging user.
We either have to ensure that this name clash does not cause any trouble
with certificates or we have to enforce uniqueness of uid across the
whole tree. For FreeIPA it's probably fine because we compare certs
bytes. Third party applications parse the cert subject instead and use
the subject to identify a user.
Christian
Hi Christian,
uniqueness of uid is not checked in staging area on purpose, it may be
changed multiple times before the stageuser is transformed into user
(activated). The uid uniqueness is then checked during activation.
Third party application that use FreeIPA's LDAP should:
1) search for users (and usercertificate attribute) only in
cn=users,cn=accounts
2) respect the value of nsAccountLock that is set to true for all staged
users.
But it would be nice to have this scenario (stageuser.uid == user.uid)
implemented as a part of [1].
[1] https://fedorahosted.org/freeipa/ticket/6615
--
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] Stageuser API
On 17.01.2017 12:38, Christian Heimes wrote:
On 2017-01-16 15:52, David Kupka wrote:
Hello everyone!
I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.
I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:
1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.
Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.
Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?
I see one potential issue in your proposal. A stage user does not
reserve its user name. The unique index on uid excludes the staging user
and deleted user branch. Therefore it is possible to create a user with
the same login name as a staging user.
We either have to ensure that this name clash does not cause any trouble
with certificates or we have to enforce uniqueness of uid across the
whole tree. For FreeIPA it's probably fine because we compare certs
bytes. Third party applications parse the cert subject instead and use
the subject to identify a user.
Christian
AFAIK the non-uniques of stageuser and user names causes more pain than
gain, this is not the first case when we have an issue with that. Maybe
we should reevaluate this behavior and enforce uid uniqueness with
stageusers too.
Note: we explicitly updated uniqueness plugin to allow conflicting names
but I don't remember the reason from top of my head.
Martin^2
--
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] Stageuser API
On 2017-01-16 15:52, David Kupka wrote:
> Hello everyone!
>
> I've noticed that our API for stageuser is missing some commands that
> user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
> there is reason for it but after asking some fellows developers it seems
> that there's none.
>
> I understand the stageuser area as a place where user entry can be
> created and amended during the hiring process in organization, example:
>
> 1. HR creates the entry with just basic informations (givenname,
> surname, manager)
> 2. IT assigns basic account information (uid, gid)
> 3. based on to-be-employee manager's request IT adds additional group
> membership (memberOf)
> 4. based on to-be-employee request IT adds login alias (krbPrincipalName)
> 5. Security Officer adds certificate from Smart Card assigned to the
> to-be-employee
> 6. HR adds extra information to the account (address, marital status, ...)
> 7. Facilities update work place related information (seat number, phone
> number, ...)
> 8. At the first day IT activates the user account.
>
> Considering this work flow I think it might be useful to have the same
> API for stageuser as for the user.
>
> Does the example work flow make sense?
> Should we provide the same set of commands for user and stageuser?
I see one potential issue in your proposal. A stage user does not
reserve its user name. The unique index on uid excludes the staging user
and deleted user branch. Therefore it is possible to create a user with
the same login name as a staging user.
We either have to ensure that this name clash does not cause any trouble
with certificates or we have to enforce uniqueness of uid across the
whole tree. For FreeIPA it's probably fine because we compare certs
bytes. Third party applications parse the cert subject instead and use
the subject to identify a user.
Christian
signature.asc
Description: OpenPGP digital signature
--
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] Stageuser API
On ti, 17 tammi 2017, Florence Blanc-Renaud wrote:
On 01/16/2017 03:52 PM, David Kupka wrote:
Hello everyone!
I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.
I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:
1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.
Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.
Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?
Thanks for your ideas and opinions!
Hi David,
I would be in favor of providing the same API for stageuser and user.
It is already possible to add a certificate or a principal alias to a
stageuser with ipa stageuser-mod --cert or ipa stageuser-mod
--principal, meaning that those operations are not forbidden.
I also checked that a stageuser
- is not able to perform kinit with any of his principal aliases
- is not able to authenticate to the LDAP server with a DN/pwd
- is not able to authenticate to the LDAP server using his SSL cert
- is not able to login with user/pwd on a client console
so I do not see any security concern with your proposal.
Thank you, Flo. Let's then proceed with the David's proposal.
For the record, we discussed this proposal on a weekly development call
and I raised the questions about authentication above. Florence
volunteered to experiment with it to see if SSL certificate
authentication would be possible. It is not, so we can unify the API
behind both user and stageuser.
--
/ Alexander Bokovoy
--
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] Stageuser API
On 01/16/2017 03:52 PM, David Kupka wrote:
Hello everyone!
I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.
I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:
1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.
Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.
Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?
Thanks for your ideas and opinions!
Hi David,
I would be in favor of providing the same API for stageuser and user.
It is already possible to add a certificate or a principal alias to a
stageuser with ipa stageuser-mod --cert or ipa stageuser-mod
--principal, meaning that those operations are not forbidden.
I also checked that a stageuser
- is not able to perform kinit with any of his principal aliases
- is not able to authenticate to the LDAP server with a DN/pwd
- is not able to authenticate to the LDAP server using his SSL cert
- is not able to login with user/pwd on a client console
so I do not see any security concern with your proposal.
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
[Freeipa-devel] Stageuser API
Hello everyone!
I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.
I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:
1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.
Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.
Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?
Thanks for your ideas and opinions!
--
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
