This explains what happens with multi-factor authentication (MFA) - the "enter a code from your authenticator app", security key, or backup code step Joomla can require after a password - when a site logs users in through RO SSO.
MFA here always means Joomla's own MFA, the same feature you'd set up under a user's Edit Account page or manage under Users -> Multi-factor Authentication. Single sign-on doesn't add a second, separate MFA system of its own - depending on which role a site plays, a login through RO SSO either passes through Joomla's existing MFA prompt, is allowed to skip it, or currently isn't checked against it at all. Which of those applies depends on whether the site is acting as a Service Provider (it sends its users elsewhere to log in) or an Identity Provider (other sites send their users to this site to log in) - covered separately below.
If this site is a Service Provider (SP)
When someone logs in here via single sign-on, this site still applies its own MFA settings locally, on top of whatever the other site (the Identity Provider) required. By default, every fresh single sign-on login still shows this site's normal MFA prompt, exactly as a direct username/password login would.
There are two situations where this site can be told to skip its own MFA prompt after an SSO login, both configured under Users -> Options -> Silent login response types in the Joomla admin - the same setting that already controls when a native Passkey login skips MFA:
- The user's browser already had a live single sign-on session. For example, an admin's Joomla session expired, but they were still signed in centrally, so logging back in here didn't actually require re-entering a password or a code anywhere. If you add the SSO "silently reused session" option to the Silent login response types list, this site's MFA prompt is skipped in that case. Leaving it off (the default) means the user sees an MFA prompt again even though they
weren't really challenged for credentials. - The Identity Provider reports that the user signed in with a passwordless method, such as a passkey, and passes that information along. Because a passwordless method is itself considered a strong second factor, this is treated the same as a native Passkey login on this site, and can be exempted the same way. Whether this ever actually happens depends entirely on the Identity Provider you're connected to - some Identity Providers report this, others don't (RO SSO's own built-in Identity Provider currently does not - see below).
If you don't add anything to the Silent login response types list, nothing changes: every SSO login is treated as fully interactive and gets this site's normal MFA prompt.
If this site is an Identity Provider (IdP)
If this site is set up to let other sites log their users in through it (Components -> RO SSO -> Configuration -> Identity Provider), be aware of an important current limitation:
RO SSO's built-in Identity Provider only checks a username and password. It does not check whether the user also has MFA configured on their account on this site, and it never asks for a second factor during single sign-on.
In practice, this means a user who has MFA required when logging into this site directly can still complete a single sign-on login to another site using just their password - the MFA step is skipped entirely for that flow, even though it would normally be enforced for a direct login here.
If enforcing MFA during single sign-on logins (not just direct logins) matters for your site, that's not something RO SSO does out of the box today - see the next section for a real-world example of a site that added it.
How Joomla Identity Portal handles this
The Identity Portal, the Joomla project's own central login site, runs on this same package as its Identity Provider and has had MFA enforcement added on top of it.
The reasoning behind that setup: identity.joomla.org is the *only* place its users manage their MFA methods (their profile page there has tabs for authenticator apps, backup codes, and passkeys), so it's also the only place that's in a position to actually check them before sending someone through to another site.
There, a single sign-on login works like this:
- The user's password is checked as normal.
- If that account has any MFA method turned on, the login doesn't complete yet - the user is shown an MFA prompt (code entry, or a choice between multiple enrolled methods, including backup codes) before anything is sent back to the site that asked for the login.
- Only once a valid code is entered does the login actually complete and the user gets sent back to the requesting site.
- Logging in with a passkey instead of a password skips this prompt, the same way a native Passkey login does elsewhere in Joomla, since a passkey is already considered a strong second factor.
This confirms MFA enforcement during single sign-on is possible, but it required custom development work specific to that site - it isn't a setting that can be turned on, and it isn't included in RO SSO as shipped.
Custom branding or a custom MFA page
The login form, error pages, and (where added, as above) the MFA prompt a user sees during single sign-on are all part of the shared login screens SimpleSAMLphp renders - similar in concept to how a Joomla template controls the look of the rest of a site, but managed separately from Joomla's own templates. identity.joomla.org's MFA prompt, for example, is shown with the same Joomla branding as the rest of its login pages, using a custom look-and-feel built specifically for that site.
Giving a site's login/MFA pages custom branding, or adding an MFA prompt page like the one above, requires development work - it's not a configuration screen. If that's something you need, expect it to involve a developer familiar with both this package and SimpleSAMLphp's theming system.