Hi all and welcome me to the list :),
i'm using koji since a few week and i needed X509 authentication. Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the "username" of the user there are cases (like in our PKI) where CN is just "Christos Triantafyllidis" and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have "EnvVarForUserName = SSL_CLIENT_S_DN" which uses the whole DN as username.
b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution.
I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them.
Best regards, Christos Triantafyllidis
[1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git
On Mon, Dec 14, 2009 at 8:03 PM, Christos Triantafyllidis ctria@grid.auth.gr wrote:
Hi all and welcome me to the list :),
i'm using koji since a few week and i needed X509 authentication. Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the "username" of the user there are cases (like in our PKI) where CN is just "Christos Triantafyllidis" and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have "EnvVarForUserName = SSL_CLIENT_S_DN" which uses the whole DN as username.
What did you do about the email address? It normally uses CN@configured.org
I should look at the patch of course. Steve
b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution.
I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them.
Best regards, Christos Triantafyllidis
[1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git
Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
On 14 Δεκ 2009, at 9:32 μ.μ., Steve Traylen steve.traylen@cern.ch wrote:
What did you do about the email address? It normally uses CN@configured.org
Well it normally uses username@domain where in my case it already invalid. I'm planning to extend the users table to include also email. So now it is DN@domain.
I should look at the patch of course. Steve
Christos
On 12/14/2009 02:03 PM, Christos Triantafyllidis wrote:
Hi all and welcome me to the list :),
Welcome, and thanks for the patches! Comments in-line.
i'm using koji since a few week and i needed X509 authentication.Unfortunately current support for x509 was limited to: a) Use of the CN part only from the subject DN as the username Although traditionally CN can be the "username" of the user there are cases (like in our PKI) where CN is just "Christos Triantafyllidis" and of course many users can have the same name but different DNs. To avoid this but also keep the backwards compatibility i have introduced a new variable to be exported by both apache config (for git-web) and hub.conf (for the rest of the tools) called EnvVarForUserName which defines which variable to use as Username. For my case i have "EnvVarForUserName = SSL_CLIENT_S_DN" which uses the whole DN as username.
koji-hub already supports a DNUsernameComponent option. Rather than introduce a new config option, I think I'd rather see "DNUsernameComponent=DN" special-cased to mean "use the whole DN". I don't see any env. vars other than DN that would be useful for authentication.
b) Keep asking the user to provide their pass-phrase many times for the the same operation This leads (IMHO) many users to use password-less certificates. Unfortunately this is not acceptable according to our PKI policy so i added a callback to cache the passphrase within each koji execution.
This looks very interesting, thanks. I'll see about testing it locally and merging it. I wonder if this could be extended to integrate with gnome-keyring (or similar) to provide once-per-session login for SSL certificates. I'll look into this.
I have created some patches to both this limitations and i have uploaded the to my git repository[1]. Feel free to use/clone them.
Best regards, Christos Triantafyllidis
[1] http://git.afroditi.hellasgrid.gr/git/grid.auth.gr/koji.git
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Hi Mike,
first of all i need to clarify that i'm not koji expert (as i said i'm using it only a few weeks).
On Dec 14, 2009, at 9:42 PM, Mike Bonnet wrote:
koji-hub already supports a DNUsernameComponent option. Rather than introduce a new config option, I think I'd rather see "DNUsernameComponent=DN" special-cased to mean "use the whole DN". I don't see any env. vars other than DN that would be useful for authentication.
Hm that sounds like a cleaner approach! Thanks. I'm going to implemented probably later today...
One special case that i can think is if one would like to use the issuer's DN or any part of it but this is not the case for me so i can skip it.
One case that (i think) is not covered even from my approach though is the usage of an X509 extension of the certificate (i.e. the SubjectAlternativeNames) but for now i can live without them.
Christos
Hi again,
On Dec 14, 2009, at 10:52 PM, Christos Triantafyllidis wrote:
Hi Mike,
first of all i need to clarify that i'm not koji expert (as i said i'm using it only a few weeks).
On Dec 14, 2009, at 9:42 PM, Mike Bonnet wrote:
koji-hub already supports a DNUsernameComponent option. Rather than introduce a new config option, I think I'd rather see "DNUsernameComponent=DN" special-cased to mean "use the whole DN". I don't see any env. vars other than DN that would be useful for authentication.
Hm that sounds like a cleaner approach! Thanks. I'm going to implemented probably later today...
DONE!
Christos
On Mon, 14 Dec 2009, Christos Triantafyllidis wrote:
i'm using koji since a few week and i needed X509 authentication.
This is interesting. Any idea, would client side pkcs11.so module sertificates work out of the box then? In my understading, the part how the certificate gets into http connection, is transparent to server.
In many european countries, there are goverment PKI cards that kind of establishes potential, authenticatable userbase automatically.
I use the id-card in browser quite a bit and especially the SSL client-cert works very well.
That would be interesting to try koji with those id-card certificates.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
Hi Tuju,
no this patch doesn't cover this case. I guess this won't be that difficult to be implemented if it is supported by pyOpenSSL the SSL part is done there.
Unfortunately my country doesn't use any PKI card but i'm also interested in using my eToken for this.
Regards, Christos
On Dec 15, 2009, at 2:52 PM, Juha Tuomala wrote:
On Mon, 14 Dec 2009, Christos Triantafyllidis wrote:
i'm using koji since a few week and i needed X509 authentication.
This is interesting. Any idea, would client side pkcs11.so module sertificates work out of the box then? In my understading, the part how the certificate gets into http connection, is transparent to server.
In many european countries, there are goverment PKI cards that kind of establishes potential, authenticatable userbase automatically.
I use the id-card in browser quite a bit and especially the SSL client-cert works very well.
That would be interesting to try koji with those id-card certificates.
Tuju
-- Ajatteleva ihminen tarvitsee unta.
-- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
buildsys@lists.fedoraproject.org
-
Christos Triantafyllidis -
Juha Tuomala -
Mike Bonnet -
Steve Traylen