GNOME Bugzilla – Bug 681975
Display enterprise login hint
Last modified: 2012-08-21 17:20:04 UTC
As part of wrapping up the Enterprise Accounts GNOME 3.6 feature [1], we should add a hint to an appropriate place in the login screen on how to log in with an enterprise login (like Active Directory), if configured. Research on this was done here, including showing what Windows does: https://live.gnome.org/StefWalter/Scratch/DirectoryLogin We could add text something like this to GDM: To log into an account at the example.com domain, type EXAMPLE\User as your user name. The domain (ie: the 'example.com' text above) and format (ie: 'EXAMPLE/User') text above would come from realmd. But as an explanation: Active Directory users domains log in as 'DOMAIN/User' as they do on Windows. Users of IPA log in as 'user@domain'. realmd configures different unix user names for the different types of realms. The text above could either be directly in the "Not listed?" page (ie: where one types a user name) since there's lots of space. Or there could be a link in the "Not listed?" page which displays the text above. Windows has such a link, see above research. Obviously none of this would show up if realmd says no domains are configured for enterprise login. It's true that enterprise logins explicitly configured via the the User Panel in gnome-control-center would show up in the GDM user chooser. However if realmd is configured from outside of GNOME, and its configured to allow any login from a domain (which is likely on a workstation), then GDM should display such a hint on how to login. I brought this up during the Login/Unlock screen hackfest at GUADEC, but I think we ran out of time to discuss it. [1] https://live.gnome.org/ThreePointFive/Features/UserPanel
Created attachment 221352 [details] The 'Not listed?' screen referred to in description
we should definitely try to get this in before monday. i'll have a look.
Cool. After discussion on #gnome-design, I had sort of given up hope on this for 3.6. But I'm happy to work with you on it. Which component do you think should generate the message, gdm or gnome-shell? Jon brought up on #gnome-design that displaying these login hints is generalizable design. Both smart cards and fingerprint logins could do with some sort of hint on how to use them.
So, to build the above string, we would need to enumerate the Realms [1] property of the org.freedesktop.realmd.Provider [2] at /org/freedesktop/realmd and look for realms that have their Configured property [3] set. For each of those realms, load the first of the LoginFormats [4] and build the string with that. After displaying the hint, since both gdm and gnome-shell are long running processes, and realmd stays alive as long as its callers do, we probably want to allow realmd to exit by calling Release() [5] on the service interface. [1] http://www.freedesktop.org/software/realmd/docs/gdbus-org.freedesktop.realmd.Provider.html [2] http://www.freedesktop.org/software/realmd/docs/gdbus-org.freedesktop.realmd.Provider.html#gdbus-property-org-freedesktop-realmd-Provider.Realms [3] http://www.freedesktop.org/software/realmd/docs/gdbus-org.freedesktop.realmd.Realm.html#gdbus-property-org-freedesktop-realmd-Realm.Configured [4] http://www.freedesktop.org/software/realmd/docs/gdbus-org.freedesktop.realmd.Realm.html#gdbus-property-org-freedesktop-realmd-Realm.LoginFormats [5] http://www.freedesktop.org/software/realmd/docs/gdbus-org.freedesktop.realmd.Service.html#gdbus-method-org-freedesktop-realmd-Service.Release
ah I missed the gnome-design discussion. Found it: <stefw> jimmac, mccann, what do you think about the enterprise login hint in the login screen? <stefw> this: https://bugzilla.gnome.org/show_bug.cgi?id=681975 <bebot`> Bug 681975: normal, Normal, ---, gdm-maint, UNCONFIRMED, Display enterprise login hint <stefw> in particular, does it seem right to add for 3.6, and if so should it be in the the 'not listed?' page itself, or perhaps a popup? <stefw> the 'not listed?' page i'm referring to: http://bugzilla-attachments.gnome.org/attachment.cgi?id=221352 <stefw> and an example of a popup on windows 7: https://live.gnome.org/StefWalter/Scratch/DirectoryLogin?action=AttachFile&do=get&target=login-windows-other-domain.png <jimmac> stefw, I guess it would do no harm to have it in as an "easter egg" (ie, completely non-discoverable) <stefw> jimmac, do you mean that it wouldn't show up when no enterprise logins are configured? <stefw> or how do you mean? <stefw> obivously the logins work regardless of the hint. <jimmac> mccann, https://www.dropbox.com/s/9xv6tw0k1u37mya/lorem.jpg deos that work? <jimmac> stefw, I dislike having "inline help" in dialogs generally <stefw> would you prefer a domain drop down selector in that case? <stefw> because we could do that <stefw> enter the domain and username in two dialogs and compose them into the full user name. <stefw> or maybe not even a drop down selector, but just another field. <stefw> although that's obviously complicated from an implementation perspective wrt PAM. <stefw> windows used to have seperate fields for domain, user, but it caused lots of complications with kerberos corner cases. <mccann> hey stefw <mccann> stefw: how is the AD hint different from the fingerprint reader hint? <stefw> mccann, i've never used a fingerprint reader with GDM :O <stefw> does the hint just mean, "use your fingerprint reader, and not this dialog?" <stefw> s/dialog/prompt/ <mccann> stefw: fingerprint, smartcard, AD all may want their own help text <stefw> true <mccann> need to think that through before we do anything I think <stefw> AD help text is on the username prompt <stefw> and the other help text is on the authentication/password prompt <stefw> but you're right, the design is generalizable <stefw> jimmac, one aspect of gdm is that it is the only (or only reasonable) way to log into a system. <mccann> stefw: not really <stefw> with other tools it's reasonable to expect users with special needs to install a more advanced tool. <mccann> smartcards and fingerprint also do identification <mccann> as well as authentication <mccann> potentially <stefw> true <stefw> good point
So currently the fingerprint hint shows up when a user clicks there name in the list and they are presented with a password screen: Password: [ ] (or swipe finger) We don't show it the user clicks "Not listed?" (I think that's a current limitation of the fingerprint stack. We can tell if a fingeprint matches a user's hash but we can't figure out what user just swiped their finger). The domain hint is sort of the other way around. It makes little sense to show after a user has been clicked in the list since users in the list have domains attached to them. The "Not Listed?" screen currently looks like this: Username: [ ] I think if we to make this follow the same pattern as fingerprint that mccann suggests we can do it like this: Username: [ ] (e.g., username or username@example)
Created attachment 221775 [details] [review] gdm: generalize fingerprint message into login hint The fingerprint message is useful for users that click their names in the user list to let them know if fingerprint login is available. This same place on screen (below the login entry) can potentially be used for other messages as well. This commit changes the variable and style names surrounding this feature to be more generic. A subsequent commit will leverage this functionality to provide a hint on how to log in to the local enterprise domain controller (if relevant).
Created attachment 221776 [details] [review] gdm: Add network login hint Different networks have different user identifers. This can be confusing to the user, so to make it clearer, we try to provide a hint.
hmm, the intertubes seemed to have dropped the message leading up those patches which was something like: "I'm going to to throw up an untested patchset that's probably not ready to go in as-is for now, since I need to switch gears back to bug 679253 for a bit."
Review of attachment 221776 [details] [review]: I tried testing and working on this, but can't get my custom installed clutter + gnome-shell working. There are really strange errors that look like incorrect versions of clutter and clutter-x11 libraries being used together. Anyway, just had a few comments without testing: ::: js/gdm/realmd.js @@ +10,3 @@ + <property name="Name" type="s" access="read"/> + <property name="Version" type="s" access="read"/> + <property name="Realms" type="a(os)" access="read"/> Where did you get this interface from. It seems part old, part new style. The signature for this proprety is now 'ao'. See: http://cgit.freedesktop.org/realmd/realmd/tree/dbus/org.freedesktop.realmd.xml @@ +15,3 @@ + <arg name="options" type="a{sv}" direction="in"/> + <arg name="relevance" type="i" direction="out"/> + <arg name="realm" type="a(os)" direction="out"/> Ditto here. @@ +115,3 @@ + newLoginFormat = realm.loginFormats[0]; + break; + } Should we handle multiple configured realms somehow? If we can't display multiple login formats, we might choose to display add an '...' to the message?
(In reply to comment #10) > Review of attachment 221776 [details] [review]: > ::: js/gdm/realmd.js > @@ +10,3 @@ > + <property name="Name" type="s" access="read"/> > + <property name="Version" type="s" access="read"/> > + <property name="Realms" type="a(os)" access="read"/> > > Where did you get this interface from. It seems part old, part new style. The > signature for this proprety is now 'ao'. It start out the old realmd interface until I noticed there was a new one, then I (mis?)merged in the new interface. We should probably change gjs to just load XML files directly and produce the objects automatically, but that's separate I guess. > Should we handle multiple configured realms somehow? If we can't display > multiple login formats, we might choose to display add an '...' to the message? Potentially. I think the main point of the hint is to show the syntax for logging in, though. May be we could show a tooltip for available realms or something like that. Could use designer input here.
(In reply to comment #11) > Potentially. I think the main point of the hint is to show the syntax for > logging in, though. May be we could show a tooltip for available realms or > something like that. > > Could use designer input here. Yeah. I'm also fine with starting simple (leaving it as is) and get fancy later once we get a bit of feedback from designers and others.
Created attachment 221950 [details] [review] gdm: generalize fingerprint message into login hint The fingerprint message is useful for users that click their names in the user list to let them know if fingerprint login is available. This same place on screen (below the login entry) can potentially be used for other messages as well. This commit changes the variable and style names surrounding this feature to be more generic. A subsequent commit will leverage this functionality to provide a hint on how to log in to the local enterprise domain controller (if relevant).
Created attachment 221951 [details] [review] gdm: Add network login hint Different networks have different user identifers. This can be confusing to the user, so to make it clearer, we try to provide a hint.
I got a chance to try the first round of patches and as expected they didn't work. This round holds up to some testing.
Review of attachment 221951 [details] [review]: Unfortunately I can't test this yet due to a broken clutter install/screw-up. But the code looks good. Just one question: ::: js/gdm/realmd.js @@ +65,3 @@ + + this._aggregateProvider.connect('notify::Realms', + Lang.bind(this, this._reloadRealms)); Are you sure the properties are in CamelCase here (and below with 'notify::Configured')? I'll admit I'm not familiar with makeProxyWrapper(), but figured I'd check.
(In reply to comment #16) > Review of attachment 221951 [details] [review]: > > Unfortunately I can't test this yet due to a broken clutter install/screw-up. > But the code looks good. Just one question: > > ::: js/gdm/realmd.js > @@ +65,3 @@ > + > + this._aggregateProvider.connect('notify::Realms', > + Lang.bind(this, this._reloadRealms)); > > Are you sure the properties are in CamelCase here (and below with > 'notify::Configured')? I'll admit I'm not familiar with makeProxyWrapper(), but > figured I'd check. In fact, there is no 'notify' support in makeProxyWrapper, since it's JS only and does not install GObject properties. You need to use g-properties-changed.
doh. I knew that.
Created attachment 222044 [details] [review] gdm: Add network login hint Different networks have different user identifers. This can be confusing to the user, so to make it clearer, we try to provide a hint.
Review of attachment 222044 [details] [review]: Mostly good ::: js/gdm/realmd.js @@ +61,3 @@ + 'org.freedesktop.realmd', + '/org/freedesktop/realmd', + Lang.bind(this, this._reloadRealms)) While Provider alone works, using "new Provider" is more consistent with gnome-shell coding style (here and below) @@ +88,3 @@ + if (!realm.Configured) { + if (this._realms[realm.get_object_path()]) + delete this._realms[realm.get_object_path()]; If realms can come and go, you probably need to disconnect g-properties-changed when deleting the object because it disappeared from Manager.Realms
Review of attachment 221950 [details] [review]: You need to adapt UnlockDialog too.
Created attachment 222048 [details] [review] gdm: generalize fingerprint message into login hint The fingerprint message is useful for users that click their names in the user list to let them know if fingerprint login is available. This same place on screen (below the login entry) can potentially be used for other messages as well. This commit changes the variable and style names surrounding this feature to be more generic. A subsequent commit will leverage this functionality to provide a hint on how to log in to the local enterprise domain controller (if relevant).
Created attachment 222049 [details] [review] gdm: Add network login hint Different networks have different user identifers. This can be confusing to the user, so to make it clearer, we try to provide a hint.
Review of attachment 222048 [details] [review]: Looks good to me
Review of attachment 222049 [details] [review]: Seems ok