"Sign in with SSO" button

[literallyjustroy]

Describe the feature request

With older versions of the Okta Widget & the classic engine you could start with the idpDiscovery feature as false, then provide a button which set it to true and re-rendered the widget. With the latest versions of the Okta Widget using the new Identity Engine this feature flag is removed and instead the routing policies are polled directly to choose what to display.

Due to some internal username constraints (emails are usernames), we have certain users who need to log in using a username and password, while the rest of their organization is using SP-Initiated SAML (via IDP Discovery).

Can we get official support for a "Sign in with SSO" button so we can support both password/username and SP-Initiated SAML for different users under the same email domain. Is there an existing workaround for this behavior?

New or Affected Resource(s)

Okta Widget IDP Discovery Sign In

Provide a documentation link

https://developer.okta.com/docs/guides/oie-upgrade-sign-in-widget/main/#registration

Additional Information?

No response

[jaredperreault-okta]

With the latest versions of the Okta Widget this feature flag is removed

Which feature flag are you referencing here, idpDiscovery? Classic still supports idpDiscovery.

Can you provide:

1. the output of npx envinfo --system --npmPackages '{@okta/*,}' --binaries --browsers
2. a code snippet of your widget config (obfuscate sensitive fields) and the logic you're using to update the config?

[literallyjustroy]

@jaredperreault-okta Sorry, I meant with the latest Okta Widget using the Identity Engine this feature flag is ignored. We'd like to use the Identity Engine because we'd like to support Self-Service Registration. I've edited the original post.

[leemchale-okta]

Hi @literallyjustroy, can you provide a screen shot of the routing rule you are using? You should be able to achieve this functionality using a routing rule that includes both the default Okta login method(username+password), aswell as your SAML IDP SSO.

[literallyjustroy]

The routing rules need to match on something, how can I match on password users to send them to Okta login vs saml users?

As well, matching on username/password users means those usernames are discoverable.

[leemchale-okta]

You could have a route that applies to everyone, and includes the Okta login as well your saml IDP button, which would allow the user to choose which way to sign in. This is an example of a route like that:

And this is what the login form would look like:

Except instead of the google IDP you would use your own. That way the user could choose to log in through one of the two methods. Let me know if that helps.

[literallyjustroy]

Ah, I see what you are saying; it doesn't look like this will work for our case. We are doing this for our customer facing login page and so need to be able to have idp discovery for numerous idps, not a single one.

[leemchale-okta]

How many idps are currently being used? You can add as many different idps as you like to that route and it would look something like this:

Would that work in this case? Although if you have a lot more idps it may start to look a bit cluttered.

[literallyjustroy]

Setting up IDP Discovery is something we're going to allow all customers to access so we'll easily clear any acceptable number of buttons here.

[literallyjustroy]

In particular, we are trying to figure out what is expected by this section in the Okta documentation:

Implementing a "backdoor" This is particularly important where the entire population is intended to be SAML-enabled in your application. Sometimes, there might be a mistake in the SAML configuration - or something changes in SAML IdP endpoints. In any case, you don't want to be completely locked out. Having a backdoor available for an administrator to use to access a locked system becomes extremely important. This is often accomplished by having a "secret" sign-in URL that doesn't trigger a SAML redirection when accessed. Typically, the administrator uses a username and password to sign in and make the necessary changes to fix the problem.

https://developer.okta.com/docs/concepts/saml/#exposing-saml-configuration-in-sp

Essentially, a customer would have all their users be SAML except for their admin account they'd use to configure their Okta SAML settings. That admin user needs to be able to login via username/password.

[leemchale-okta]

yes using the backdoor login link could be a good way for the admin to bypass the custom sign in route. You simply add /login/default to the end of your Okta URL to look like this: https://${yourOktaDomain}/login/default

More info here: https://developer.okta.com/docs/guides/custom-widget/-/main/#bypass-the-custom-sign-in-page

[leemchale-okta]

for the users you can set up a routing rule to redirect users to the correct IdP based on their username (using regex pattern), domain, User attribute, or application being accessed.

Security > Identity Providers > Routing Rules tab

[literallyjustroy]

The functionality for the login/default is exactly what we are looking for, however, we need this to be the behavior to be triggerable from a button on the embedded login widget.

We could instead have two separate widgets that target different applications which are really the same application but just have a division in order to use different routing rules.

[literallyjustroy]

Can we use the same logic that login/default does to ignore routing rules?

[leemchale-okta]

Can we use the same logic that login/default does to ignore routing rules?

I dont think we can ignore routing rules on the client side

We could instead have two separate widgets that target different applications which are really the same application but just have a division in order to use different routing rules.

I think technically you could set up another okta app to use as an IDP for username/password login, but that may be overkill.

The functionality for the login/default is exactly what we are looking for, however, we need this to be the behavior to be triggerable from a button on the embedded login widget.

Okay, I will discuss this in a meeting with the team and look into this.

Also just to clarify, are you self hosting the embedded widget? Or are you using an okta hosted widget? Thanks!

[literallyjustroy]

Thanks a ton for looking into this. We are indeed self-hosting the embedded widget.

[literallyjustroy]

Hey @leemchale-okta any update on this?

[leemchale-okta]

Hi @literallyjustroy, sorry we haven't been able to look at this yet, but we have a ticket to track this now and will be looking into it shortly

[leemchale-okta]

Internal Ref: OKTA-617316

[leemchale-okta]

@literallyjustroy just to clarify, you have customers that will be signing in using a SAML IDP, but you want an admin to be able to sign in through the default Okta username/password route?

Could you possibly use this Custom buttons API? To create a button on the sign in page that when clicked could redirect the user to the default okta login.

[literallyjustroy]

@leemchale-okta That'd technically work, however, would require that customers be routed to an Okta hosted page. Ideally we'd like to keep the flow entirely on our site.

[leemchale-okta]

@literallyjustroy can you also check out creating a routing rule based on a users attribute (ie. an admin attribute). I think you can check if the user has an admin attribute, then route them to the password login if they do. More info here

[literallyjustroy]

That's our current plan if another solution doesn't pan out. That has the unfortunate side affect of making admin account emails far more discoverable. As well, it doesn't let us match only on "saml" users, so we also need to add an attribute to all our existing users.

[leemchale-okta]

After discussing with the team we have found that this not a client code change that we can make since the back end will not support this. I believe the closest solution to making it behave like it did in Classic is to have two OIDC apps, the first app id is rendered with a rule that only allows Okta. Then have a custom button as you did before that will cancel the transaction, reconfigure the widget for the other app id and then render again. The routing rule for this app id would have all the other IdPs. This assumes that you can handle tokens from either app.

The second alternative work around is to route users based on user attribute like you mentioned.

If you need more help implementing these solutions you will have to reach out to Okta support since this github issues forum is for code related changes only. Since this is no longer a code related change I will have to close this issue. Sorry for any inconvenience and thank you for your patience!

[literallyjustroy]

No problem at all. Thanks for your help