In response to Windows users getting NTLM/basic auth dialogs and perhaps for user-choice in general, Simo has a proposal for a landing page.
All expired or no cookie browser users would be redirected to a landing page with buttons for each authentication method, like:
This also makes it easier for a user to log in as someone else, e.g. having your own Kerberos credentials but logging into the UI as admin.
Getting the UA right would be important so this doesn't affect CLI or API users.
IPA uses an xmlrpc-generated UI, like:
User-Agent: xmlrpclib.py/1.0.1 (by www.pythonware.com)
Ideally this is well-commented in the Apache config so can be overridden to the old behavior by users, with the appropriate warnings that upgrades may revert the changes.
In Web UI, In practice it will mean that Web UI should not automatically do a request to /ipa/sessions/login_kerberos. The rest we have.
Metadata Update from @pvomacka:
- Issue tagged with: webui
Metadata Update from @pvoborni:
- Issue set to the milestone: FreeIPA 4.7
Metadata Update from @rcritten:
- Issue set to the milestone: FreeIPA 4.7.1 (was: FreeIPA 4.7)
FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone
On the technical side:
On loading it tries Kerberos login (/ipa/session/login_kerberos) automatically first. If it fails it shows login dialog, if it succeeds, it goes to default page (user search page). On the login page, there are fields for username and password + login button. There is also "Log In Using Certificate" link and "Sync OTP Token" link.
Configuration can be either per-user or server-wide. Storing Web UI config in user entry is usually not desirable, per-user config can be also stored on the client side, but that does not add much value (what would be the use case?). So the only usable part can server-wide config. Note: I can see a use case for group-wide config, but that might be more technically challenging.
Let's focus on server-side, server-wide configuration. We can store the data in LDAP, e.g. the same way as in ipa-config plugin. The format can be various, e.g. can be in multiple attributes, in one attribute as JSON or something else. Doesn't matter much at this moment, something good can be picked. A problem could lie in getting the data. We need to fetch the data when we don't have user credentials - when we are not authenticated yet. Presence for such method is /ipa/i18n_messages. The difference is that this method doesn't use LDAP for getting the values we either need to allow anonymous read or allow to use e.g. IPA servers HTTP principal to fetch the data.
The configuration itself can have these attrs for each auth method:
Possibly we can also have redirect page where admin can define what is the initial page after login.
With this config, Web UI can do the automatic behavior as needed and display the auth methods as wanted. It doesn't prevent the users to work around the UI and try to login manually via the not-displayed methods, so it is not a security feature but rather only UX feature.
The "empty fields implies Kerberos login" is new to me. Should we have some text to indicate that on the login page itself?
It is written there.
If the page would be touched it would be good to do also a little redesign to match the latest PatternFly design. Current login page design matches a draft of PatternFly design before it was finalized.
to comment on this ticket.