Overridden alternative authentication methods

[ricsxn]

Once the OIDC plugin is enabled and selecting the SignIn link, OIDC authentication starts immediately. I expected the standard login panel still offering me the option to select OIDC among other types of authentication methods enabled and configured in the portal (I had the standard username / password plus another offered by a third-party module). My test was performed on a newly installed Liferay Community Edition Portal 7.0.5 GA6

[gvanderploeg]

Hi,

In general I'd expect that when using OpenID Connect, using a trusted Identity Provider (=OpenID Provider), you'd want full control over the authentication mechanism and only allow the OIDC flow to be used.
However, I admit there might be more open setups in which you do allow users to choose their own type of authentication mechanism.

I think we should mark this as an enhancement.

By the way: I can think of a workaround for now: did you know that if you place the Sign-In portlet on a public page, you can still authenticate using user/pass? You could then combine that with a JSP-override / Dynamic Include to insert a link to the OIDC process (link to /c/portal/login) to let the user choose.

Hope this helps.

[ricsxn]

I was asking because I was unsure if it was the normal behaviour or due to a misconfiguration especially because I was also including another one third party SSO module.
I could try to follow your suggestion, of course keeping an eye on your next updates.
Great module and great support,
Many thanks!

[ricsxn]

I tried to follow your suggestion adding SignIn portlet inside the main window of the Liferay site (the one you find after the installation). The result was the possibility to SignIn using other registered kind of authentication, but I lost your OpenID Connect. Pressing SingIn label, the standard login window appears, I can select username/password and the other kind of authentication, but I cannot use OpenId anymore.

[gvanderploeg]

This is a quirk of the Liferay Sign-In-portlet. If that portlet is rendered on the active page, a click on the 'sign-in'-link in the upper right does not lead you to /c/portal/login but instead focuses the already rendered Sign-In-portlet, thereby bypassing all other configured login mechanisms.
I'm not sure how to mitigate this in your exact use case, but indeed it's something to be aware of.