I need to use a university’s Shibboleth instance. I assume in this scenario that Auth0 is a Service Provider for the Shibboleth instance. I’ve read about IdP Initiated SSO. Is there a way to initiate the process against the IdP from the app without asking for the user name and password? I want the user to click a button that says “Login”, which takes them to the Uni’s SSO login, which will call Auth0, which will return back to the app. It seems like Lock could do this, but it needs a username/email field. I’m not allowed to ask for this.
You’re correct that this would be a scenario where Auth0 would act as service provider for the Shibboleth instance, however, given it would be Auth0 starting the flow (clicking the button) then this would technically be SP-Initiated flow and not IdP-Initiated.
The thing to consider here is that Lock handling of enterprise connections differs depending on how many connections are enabled. If there’s only one connection enabled/allowed and that connection is an enterprise connection Lock displays a button that when clicked starts the authentication flow with the upstream IdP (in this case Sibboleth). This would match your exact requirement, however, as soon as there’s more than one connection enabled Lock changes the handling to be based on home realm discovery through emails.
In other words, if you have a database connection and your enterprise connection you could configure the enterprise one stating that email addresses ending with
@example.com are meant to login through this connection (https://auth0.com/docs/libraries/lock/v11/selecting-the-connection-for-multiple-logins#using-email-domains-with-enterprise-connections).
With the above configuration if you then input
email@example.com in the email address field Lock will hide the password input and offer only a login button that takes the user to the upstream identity provider. This does not match your exact requirements because a user would need to first input an email address.
However, instead of Lock you can consider the usage of Auth0.js which provides only an API that you could then use to implement your specific user requirements. In particular, you could have a button always visible that starts the flow with the upstream identity provider.