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.

FreeIPA 4.7 has been released, moving to FreeIPA 4.7.1 milestone

On the technical side:

How Web UI works now

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.

Username + Password + Login button

• If login button is clicked or enter is pressed, but nothing is filled in the fields a Kerberos auth is tried - /ipa/session/login_kerberos
• if something is filled in the fields, forms based auth is used - /ipa/session/login_password

Certificates/Smart Cards

• "Log In Using Certificate" is clicked then /ipa/session/login_x509

Posible enhancements

The order of things and behavior is completely changeable on Web UI side. If the project decides to automatically try /ipa/session/login_x509 than /ipa/session/login_kerberos and then display or not display username+password fields then it can be implemented by changes only in Web UI JavaScript code. The harder part is making in configurable, but that is also solvable.

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:

• enabled: yes/ no, applies to all
• automatic: yes/no, applies to /ipa/session/login_x509 and /ipa/session/login_kerberos
• order: applies to the ones with automatic: yes

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.

https://www.patternfly.org/pattern-library/application-framework/login-page/