By: Stephen Charlton user 09 Nov 2021 at 4:40 a.m. CST

1 Response
Stephen Charlton gravatar
We are evaluating Gluu in the context of an application which requires complex registration and login journeys. The main peculiarities are: - our registration journey is effectively a just-in-time login journey - we need to switch from registration to login and vice-versa in specific edge cases - we need to be able to suspend a registration or login journey and later resume it - we need to add custom and external authenticators One example would be: When user creates an account with email and password, we want to send an email to the address entered by the user and suspend the account until the email is verified. When user clicks the link, we set the account to email verified and the user can enrol additional authenticators, for example SMS. Eventually, at the end of the registration journey, we want to sign in users and redirect to the relying party with authorization code. Another example would be: During sign-in we need to authenticate users against an external authenticator hosted at its own url. For that we effectively need to suspend the Gluu login journey and resume it later by redirecting back to Gluu once done with the external authenticator. So far, our understanding is that to be able to redirect to the relying party after authentication, a Gluu session must have been created and user must have been authenticated in Gluu within that session. That session appears to be accessible only when running an interception script as a result of hitting the /authorize endpoint. As such, as far as we understand, any of the journeys above (just-in time login, email verification, return from external authenticator...) needs to start from a call to /authorize. We can use acr_values query parameter appended to /authorize, and we have managed to create working journeys for just-in-time login and email verification. However, we are wondering whether: - Is this the correct approach ? Is there a different / better one ? - How can we make this approach scalable ? Our interception script is becoming unmaintainable given that we need to map steps to authenticators up front. - The external authenticator may require a single step (i.e. come back from external authenticator) whether typical authenticators may require two (challenge + verify). This is fine as long as the authenticators are run in sequence, however we want to offer users the ability to select authenticators at runtime. Is there a sensible approach to dynamically resolve the next step ? If the answer is Casa, how could we do this? We do not think we would use the features on the Casa portal side. We also have a requirement for users to be able to authenticate with multiple second factors (for example: password, OTP SMS and then an authentication App). Gluu Casa is tailored towards users having to authenticate with one second factor only. Many thanks in advance, Stephen

By Mohib Zico staff 22 Nov 2021 at 7:09 a.m. CST

Mohib Zico gravatar
Hi Stephen, Customization questions are generally not covered in community tickets; reason behind of that is: - Customization is unique to specific organization. - Generally it require a great amount of back and forth discussion. Best way to discuss your plan is in call. Please feel free to book a call here and we will be happy to discuss: https://gluu.org/booking/