Hello, I've been writing some text to integrate freeipa/sssd with openconnect server [0], and for single password or OTP that seems to integrate seamlessly. However, when PAM-SSSD is configured to use smart cards, that only works with locally inserted cards. That is even if one uses the smart card to establish the channel used for VPN, the PAM module wouldn't know that. Would it make sense to use a flag (e.g., via pam_putenv()) and the caller of the PAM functions set the information provided by the certificate used for the session for SSSD to assume a card is present? (*)
regards, Nikos
[0]. https://github.com/openconnect/recipes/blob/master/ocserv-freeipa.md
(*). Unfortunately with TLS you can verify a signature from a smart card but you cannot have a proof that you did it recently.
On Mon, Sep 14, 2015 at 11:25:39AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I've been writing some text to integrate freeipa/sssd with openconnect server [0], and for single password or OTP that seems to integrate seamlessly. However, when PAM-SSSD is configured to use smart cards, that only works with locally inserted cards. That is even if one uses the smart card to establish the channel used for VPN, the PAM module wouldn't know that. Would it make sense to use a flag (e.g., via pam_putenv()) and the caller of the PAM functions set the information provided by the certificate used for the session for SSSD to assume a card is present? (*)
Hi Nikos,
I'm not sure I can follow, can you described with a bit more details how it should work?
bye, Sumit
regards, Nikos
[0]. https://github.com/openconnect/recipes/blob/master/ocserv-freeipa.md
(*). Unfortunately with TLS you can verify a signature from a smart card but you cannot have a proof that you did it recently.
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, 2015-09-14 at 11:46 +0200, Sumit Bose wrote:
On Mon, Sep 14, 2015 at 11:25:39AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I've been writing some text to integrate freeipa/sssd with openconnect server [0], and for single password or OTP that seems to integrate seamlessly. However, when PAM-SSSD is configured to use smart cards, that only works with locally inserted cards. That is even if one uses the smart card to establish the channel used for VPN, the PAM module wouldn't know that. Would it make sense to use a flag (e.g., via pam_putenv()) and the caller of the PAM functions set the information provided by the certificate used for the session for SSSD to assume a card is present? (*)
I'm not sure I can follow, can you described with a bit more details how it should work?
Hi Sumit,
Let's assume the following scenario. SSSD requires a password + smart card to login.
The openconnect server could require the user to use a certificate to access the VPN, and for that the administrator configures the certificates accepted by ocserv to be the same as the ones accepted by SSSD (same CA). So when the user is remote and connects to the VPN he has already used the smart card. So when the openconnect server calls PAM to authenticate the user, and SSSD is the PAM backend, it may be desirable to allow the user to login, since the smart card was present remotely, even if it was not present on the system login is done. Is the use case clear?
About the implementation, I don't have a concrete idea, but we will need to provide out-of-band information to pam_sssd on whether a certificate was used. I saw that pam_putenv() and pam_getenv() were there and they look like a good candidate for such data. For example the server could call: pam_putenv("DN=BASE64(DN)") pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)") pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
and pam_sssd() check using pam_getenv("DN"), pam_getenv("ISSUER_DN") or simply KEY_HASH, whether the strings match the expected user key. Is that reasonable?
regards, Nikos
On Mon, Sep 14, 2015 at 12:10:31PM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2015-09-14 at 11:46 +0200, Sumit Bose wrote:
On Mon, Sep 14, 2015 at 11:25:39AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I've been writing some text to integrate freeipa/sssd with openconnect server [0], and for single password or OTP that seems to integrate seamlessly. However, when PAM-SSSD is configured to use smart cards, that only works with locally inserted cards. That is even if one uses the smart card to establish the channel used for VPN, the PAM module wouldn't know that. Would it make sense to use a flag (e.g., via pam_putenv()) and the caller of the PAM functions set the information provided by the certificate used for the session for SSSD to assume a card is present? (*)
I'm not sure I can follow, can you described with a bit more details how it should work?
Hi Sumit,
Let's assume the following scenario. SSSD requires a password + smart card to login.
The openconnect server could require the user to use a certificate to access the VPN, and for that the administrator configures the certificates accepted by ocserv to be the same as the ones accepted by SSSD (same CA). So when the user is remote and connects to the VPN he has already used the smart card. So when the openconnect server calls PAM to authenticate the user, and SSSD is the PAM backend, it may be desirable to allow the user to login, since the smart card was present remotely, even if it was not present on the system login is done. Is the use case clear?
This sounds similar to the Apache use-case Jan is working on where Apache verifies that the certificate is valid and the client knows the private key.
In general this sounds similar to cases where the application is doing the authentication on it's own as e.g. ssh using ssh-keys or general GSSAPI authentication.
In all cases the application just does not call pam_authenticate() but goes to pam_acct_mgmt() immediately after calling pam_start(). This way the PAM stack is only used for access control (and maybe session setup later on) but the authentication step is skipped.
About the implementation, I don't have a concrete idea, but we will need to provide out-of-band information to pam_sssd on whether a certificate was used. I saw that pam_putenv() and pam_getenv() were there and they look like a good candidate for such data. For example the server could call: pam_putenv("DN=BASE64(DN)") pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)") pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
and pam_sssd() check using pam_getenv("DN"), pam_getenv("ISSUER_DN") or simply KEY_HASH, whether the strings match the expected user key. Is that reasonable?
In the Apache use case mentioned above Apache calls SSSD via DBus to resolves the user with the help of the certificate, please have a look at https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate for details. Would this work for you as well?
bye, Sumit
regards, Nikos
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Mon, Sep 14, 2015 at 06:40:14PM +0200, Sumit Bose wrote:
This sounds similar to the Apache use-case Jan is working on where Apache verifies that the certificate is valid and the client knows the private key.
Right, we don't really investigate how the client managed to get the certificate to us and how long ago they presented the PIN -- we just see the TLS session with the certificate verified by mod_ssl.
In all cases the application just does not call pam_authenticate() but goes to pam_acct_mgmt() immediately after calling pam_start(). This way the PAM stack is only used for access control (and maybe session setup later on) but the authentication step is skipped.
Right.
About the implementation, I don't have a concrete idea, but we will need to provide out-of-band information to pam_sssd on whether a certificate was used. I saw that pam_putenv() and pam_getenv() were there and they look like a good candidate for such data. For example the server could call: pam_putenv("DN=BASE64(DN)") pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)") pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
and pam_sssd() check using pam_getenv("DN"), pam_getenv("ISSUER_DN") or simply KEY_HASH, whether the strings match the expected user key. Is that reasonable?
In the Apache use case mentioned above Apache calls SSSD via DBus to resolves the user with the help of the certificate, please have a look at https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate for details. Would this work for you as well?
Wild idea here -- could we run the pam_start with the certificate as the login name parameter and pam_sss.so would check that the login name has newlines in it and starts with the correct PEM armor, so it would do the (equivalent of) org.freedesktop.sssd.infopipe.Users.FindByCertificate internally? We would then need a way to pass the username (login) back via some PAM env variable to the application.
On Mon, Sep 14, 2015 at 07:41:13PM +0200, Jan Pazdziora wrote:
On Mon, Sep 14, 2015 at 06:40:14PM +0200, Sumit Bose wrote:
This sounds similar to the Apache use-case Jan is working on where Apache verifies that the certificate is valid and the client knows the private key.
Right, we don't really investigate how the client managed to get the certificate to us and how long ago they presented the PIN -- we just see the TLS session with the certificate verified by mod_ssl.
In all cases the application just does not call pam_authenticate() but goes to pam_acct_mgmt() immediately after calling pam_start(). This way the PAM stack is only used for access control (and maybe session setup later on) but the authentication step is skipped.
Right.
About the implementation, I don't have a concrete idea, but we will need to provide out-of-band information to pam_sssd on whether a certificate was used. I saw that pam_putenv() and pam_getenv() were there and they look like a good candidate for such data. For example the server could call: pam_putenv("DN=BASE64(DN)") pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)") pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
and pam_sssd() check using pam_getenv("DN"), pam_getenv("ISSUER_DN") or simply KEY_HASH, whether the strings match the expected user key. Is that reasonable?
In the Apache use case mentioned above Apache calls SSSD via DBus to resolves the user with the help of the certificate, please have a look at https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate for details. Would this work for you as well?
Wild idea here -- could we run the pam_start with the certificate as the login name parameter and pam_sss.so would check that the login name has newlines in it and starts with the correct PEM armor, so it would do the (equivalent of) org.freedesktop.sssd.infopipe.Users.FindByCertificate internally? We would then need a way to pass the username (login) back via some PAM env variable to the application.
Of course you can put the certificate as a login name to pam_start() but I think this won't help much because the application has to call one of the public PAM calls like pam_authenticate(), pam_setcred(), pam_acct_mgmt(), ... to make libpam pass the value to pam_sss. I think we would misuse the PAM inferface here.
What might be better is to put the certificate as the user name to getpwnam() and let the SSSD NSS responder do the lookup. However I would prefer to do it via InfoPipe because other NSS modules might not be happy to see such user name.
bye, Sumit
-- Jan Pazdziora | adelton at #ipa*, #brno Senior Principal Software Engineer, Identity Management Engineering, Red Hat
On Mon, 2015-09-14 at 18:40 +0200, Sumit Bose wrote:
On Mon, Sep 14, 2015 at 12:10:31PM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2015-09-14 at 11:46 +0200, Sumit Bose wrote:
On Mon, Sep 14, 2015 at 11:25:39AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I've been writing some text to integrate freeipa/sssd with openconnect server [0], and for single password or OTP that seems to integrate seamlessly. However, when PAM-SSSD is configured to use smart cards, that only works with locally inserted cards. That is even if one uses the smart card to establish the channel used for VPN, the PAM module wouldn't know that. Would it make sense to use a flag (e.g., via pam_putenv()) and the caller of the PAM functions set the information provided by the certificate used for the session for SSSD to assume a card is present? (*)
I'm not sure I can follow, can you described with a bit more details how it should work?
Hi Sumit,
Let's assume the following scenario. SSSD requires a password + smart card to login.
The openconnect server could require the user to use a certificate to access the VPN, and for that the administrator configures the certificates accepted by ocserv to be the same as the ones accepted by SSSD (same CA). So when the user is remote and connects to the VPN he has already used the smart card. So when the openconnect server calls PAM to authenticate the user, and SSSD is the PAM backend, it may be desirable to allow the user to login, since the smart card was present remotely, even if it was not present on the system login is done. Is the use case clear?
This sounds similar to the Apache use-case Jan is working on where Apache verifies that the certificate is valid and the client knows the private key.
Correct.
In general this sounds similar to cases where the application is doing the authentication on it's own as e.g. ssh using ssh-keys or general GSSAPI authentication.
In all cases the application just does not call pam_authenticate() but goes to pam_acct_mgmt() immediately after calling pam_start(). This way the PAM stack is only used for access control (and maybe session setup later on) but the authentication step is skipped.
Well, that way there can be no password or OTP asked from the user, thus preventing using the certificate as second factor, and the password as first factor. I think the use-case of having certificates as single factor only is interesting but is rather a corner case.
What I would like to handle is all use cases involving certificates: 1. password + certificate 2. password + OTP + certificate 3. OTP + certificate 4. certificate only
If pam_authenticate() is skipped only (4) can be handled.
About the implementation, I don't have a concrete idea, but we will need to provide out-of-band information to pam_sssd on whether a certificate was used. I saw that pam_putenv() and pam_getenv() were there and they look like a good candidate for such data. For example the server could call: pam_putenv("DN=BASE64(DN)") pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)") pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
and pam_sssd() check using pam_getenv("DN"), pam_getenv("ISSUER_DN") or simply KEY_HASH, whether the strings match the expected user key. Is that reasonable?
In the Apache use case mentioned above Apache calls SSSD via DBus to resolves the user with the help of the certificate, please have a look at https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificat e for details. Would this work for you as well?
I think the design document is about a related but different problem. It is about mapping the certificate user name to the actual user. In ocserv, that is being done by the administrator configuring the Distinguished name field that will be used to obtain the username. The common cases are using the CN(2.5.4.3) or the UID(0.9.2342.19200300.100.1.1).
The document above tries a different approach (contacting LDAP), but I think that's not necessary if some conventions are followed.
regards, Nikos
On Tue, Sep 15, 2015 at 11:03:06AM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2015-09-14 at 18:40 +0200, Sumit Bose wrote:
On Mon, Sep 14, 2015 at 12:10:31PM +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2015-09-14 at 11:46 +0200, Sumit Bose wrote:
On Mon, Sep 14, 2015 at 11:25:39AM +0200, Nikos Mavrogiannopoulos wrote:
Hello, I've been writing some text to integrate freeipa/sssd with openconnect server [0], and for single password or OTP that seems to integrate seamlessly. However, when PAM-SSSD is configured to use smart cards, that only works with locally inserted cards. That is even if one uses the smart card to establish the channel used for VPN, the PAM module wouldn't know that. Would it make sense to use a flag (e.g., via pam_putenv()) and the caller of the PAM functions set the information provided by the certificate used for the session for SSSD to assume a card is present? (*)
I'm not sure I can follow, can you described with a bit more details how it should work?
Hi Sumit,
Let's assume the following scenario. SSSD requires a password + smart card to login.
The openconnect server could require the user to use a certificate to access the VPN, and for that the administrator configures the certificates accepted by ocserv to be the same as the ones accepted by SSSD (same CA). So when the user is remote and connects to the VPN he has already used the smart card. So when the openconnect server calls PAM to authenticate the user, and SSSD is the PAM backend, it may be desirable to allow the user to login, since the smart card was present remotely, even if it was not present on the system login is done. Is the use case clear?
This sounds similar to the Apache use-case Jan is working on where Apache verifies that the certificate is valid and the client knows the private key.
Correct.
In general this sounds similar to cases where the application is doing the authentication on it's own as e.g. ssh using ssh-keys or general GSSAPI authentication.
In all cases the application just does not call pam_authenticate() but goes to pam_acct_mgmt() immediately after calling pam_start(). This way the PAM stack is only used for access control (and maybe session setup later on) but the authentication step is skipped.
Well, that way there can be no password or OTP asked from the user, thus preventing using the certificate as second factor, and the password as first factor. I think the use-case of having certificates as single factor only is interesting but is rather a corner case.
What I would like to handle is all use cases involving certificates:
- password + certificate
- password + OTP + certificate
- OTP + certificate
- certificate only
If pam_authenticate() is skipped only (4) can be handled.
If pam_cert_auth is on set in sssd.conf or if no Smartcard reader is connected to the ocserv host then 1 and 2 should already work if ocserv calls pam_authenticate() for the user. Depending on the server setting SSSD would ask for a password or for password and OTP value.
3 is currently not supported by SSSD because SSSD currently always expects a second factor here.
HTH
bye, Sumit
About the implementation, I don't have a concrete idea, but we will need to provide out-of-band information to pam_sssd on whether a certificate was used. I saw that pam_putenv() and pam_getenv() were there and they look like a good candidate for such data. For example the server could call: pam_putenv("DN=BASE64(DN)") pam_putenv("ISSUER_DN=BASE64(ISSUER-DN)") pam_putenv("KEY_HASH=HEX(SHA256(SubjectPublicKeyInfo field))")
and pam_sssd() check using pam_getenv("DN"), pam_getenv("ISSUER_DN") or simply KEY_HASH, whether the strings match the expected user key. Is that reasonable?
In the Apache use case mentioned above Apache calls SSSD via DBus to resolves the user with the help of the certificate, please have a look at https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificat e for details. Would this work for you as well?
I think the design document is about a related but different problem. It is about mapping the certificate user name to the actual user. In ocserv, that is being done by the administrator configuring the Distinguished name field that will be used to obtain the username. The common cases are using the CN(2.5.4.3) or the UID(0.9.2342.19200300.100.1.1).
The document above tries a different approach (contacting LDAP), but I think that's not necessary if some conventions are followed.
regards, Nikos
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel@lists.fedorahosted.org
-
Jan Pazdziora -
Nikos Mavrogiannopoulos -
Sumit Bose