-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Passwordless gdm krb5 updates #10
base: passwordless_gdm
Are you sure you want to change the base?
Passwordless gdm krb5 updates #10
Conversation
To be deleted before opening PR to master branch. Signed-off-by: Iker Pedrosa <[email protected]>
This API gets the selected response type data from the response_data linked list. Includes unit tests. Signed-off-by: Iker Pedrosa <[email protected]> Signed-off-by: Ray Strode <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Integration with GDM requests two prompts for EIdP so adding them to prompt_config structure. In addition, implement all the functions needed to manipulate the structure for these new prompts. Finally, add unit-tests for the new functions. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
These new options are needed by the GDM integration, but they can be reused for CLI prompting. :config: New options to tune EIdP prompting: 'init_prompt' and 'link_prompt'. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Return `prompt_config` structure in `pam_eval_prompting_config` to tune the prompts from the SSSD config in the GUI. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Implement a set of functions to check the available authentication mechanisms and their associated data, and generate a JSON message with it. This JSON formatted message will be consumed by apps that provide GUI login (i.e. GDM). Currently, the implementation only takes into account password and OAUTH2 mechanisms. Include unit tests to check the implemented functions. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Implement a set of functions to unpack the JSON reply from the GUI. Include unit tests to check the implemented functions. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Implement a function to check whether the PAM service file in use is enabled for the JSON procotol. This helps us filter which applications are compatible with this protocol. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
This new option is used to enable the JSON protocol in the PAM responder based on the PAM service file in use. :config: Add pam_json_services option to enable JSON protocol to communicate the available authentication mechanisms. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Call JSON message generation function and fill the data structure containing the response_data linked list. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Forward the available authentication mechanisms and their associated data message to the GUI login using a PAM conversation. Then, obtain the reply and forward it to the responder, so that it can parse it. Signed-off-by: Iker Pedrosa <[email protected]> Signed-off-by: Ray Strode <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Parse GUI reply and set the appropriate data in `sss_auth_token` structure. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
Include JSON message where applies. Signed-off-by: Iker Pedrosa <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> Reviewed-by: Sumit Bose <[email protected]>
handle password changes for IPA users with multiple auth types set (passkey, password) (cherry picked from commit 89405c8748c7b596664a0c928bcd719ad99983bf)
Originally where there was only password and OTP authentication we checked for password authentication and used OTP as a fallback. This was continued as other (pre)-authentication types were added. But so far only one authentication type was returned. This changed recently to allow the user a better selection and as a result OTP cannot be handled as a fallback anymore but has to be added to the selection. In case there are no types (questions) available now password is used as a fallback. Resolves: SSSD#7152 Reviewed-by: Alejandro López <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> (cherry picked from commit bf6cb6d) (cherry picked from commit d3a9f0c588633da2f93e313a55ab3ccf7054af44)
Resolves: SSSD#7152 Reviewed-by: Alejandro López <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> (cherry picked from commit 7c33f9d) (cherry picked from commit bca3c895649546afb755746e01080cee42c8bf77)
Resolves: SSSD#7152 Reviewed-by: Alejandro López <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> (cherry picked from commit e26cc69) (cherry picked from commit a987acf82067edf90304a315070fbc17e364ee54)
The current behavior is that Smartcard authentication is preferred if possible, i.e. if a Smartcard is present. Since the Smartcard (or equivalent) must be inserted manually the assumption is that if the user has inserted it they most probably want to use it for authentication. With the latest patches pam_sss might receive multiple available authentication methods. With this patch the checks for available authentication types start Smartcard authentication to mimic the existing behavior. Resolves: SSSD#7152 Reviewed-by: Alejandro López <[email protected]> Reviewed-by: Justin Stephenson <[email protected]> (cherry picked from commit 0d5e8f1) (cherry picked from commit 98a712c1d9d1a1ed758ff1b89d33c3a9ce548522)
Before the recent patches which allow krb5_child to iterate over all available authentication methods typically only one method was returned. E.g. is Smartcard authentication (pkinit) was possible it was typically the first method the in question list and the result of the answer_pkinit() function was immediately returned. As a result only the Smartcard authentication type was set and a missing password authentication type while others were present might have been a reasonable indicator for the online state. With the recent patches, all available methods, including password authentication if available, are return and a new indicator is needed. (cherry picked from commit 163db84) (cherry picked from commit 7d20f5818191b95c3c0947299945000ff9a05955)
Hi Justin, IIUC, the problem is that I'm using an old The reason I am using such an old revision is that I faced some problems running smartcard tests and SSSD as non-root. At that time, 3-4 months ago, all this SSSD as non-root was still at work and was not stable. This should probably work properly now that we have a released version and the QE team has had enough time to test it. |
aaac845
to
b62150a
Compare
This branch is a bit behind, once I pulled in these commits from SSSD master I was able to login when selecting 'password' at the graphical login for a user with auth types 'IDP', and 'Password'.