duo-example Success Shows Login Screen about duo_universal_java HOT 5 CLOSED

@ioplex That's definitely not the expected behavior after completing 2FA. I know that there's a variety of errors that can happen to send you back to that page, but they are supposed to trigger an error message that would show up. I wonder if you're somehow hitting an error we didn't expect or don't handle correctly. My other hunch is that perhaps your redirectUri configuration is wrong somehow.

If you're up for a little debugging, you could try stepping through the duoCallback method in LoginController.java line 128 to see where things are going wrong.

from duo_universal_java.

You are correct. I just needed to set:

duo.redirect.uri=http://localhost:8080/duo-callback

Now the example works fine. This is stated clearly in the SDK documentation but it might help newbies like me if you explicitly state this in your example doc since the example is hard-coded to redirect to /duo-callback.

I guess I was expecting the end-user to just get redirected back to where they entered and not some pre-defined fixed point.

I'm trying to integrate the Universal Prompt with an Enterprise SSO solution as in Kerberos / NTLM style where no password is entered at all so there's no login form. It would be nice if the end-user could be redirected back to whatever resource they tried to access initially. But I can see trying to do that is potentially problematic.

from duo_universal_java.

Glad you got it working!

Let me see if there's a good way to clarify this in the documentation or example code. It is tricky, because the redirect is actually still part of the authentication flow - the auth isn't finalized until the application consumes the code that Duo sends back. That's why the redirect is to a fixed point - i.e. the application code that knows what to do with the code. So getting the user back to where they wanted to go in the first place has to happen after that, and only if the authentication succeeded, etc. etc.

from duo_universal_java.

Do you really have to do it after?

If a filter style handler were used and the state and duoCode parameters are supplied and the state parameter maps to a valid username, then that is pretty selective.

    if (clientSuppliedValidSignedCookie(request)) {
        doFilter(request, response);
    } else if (state == null ||
            duoCode == null ||
            username.equals(stateMap.remove(state)) == false) {
        duoClient.healthCheck();
        ...
    } else {
        Token token = duoClient.exchangeAuthorizationCodeFor2FAResult(duoCode, username);
        ...
        setSignedCookie(username, integrationKey, timestamp);
    }

But Client, in duo-example at least, is instantiated once and the redirectUri is a property of that shared Client. That's fine. All ops are re-entrant and so having one shared Client is an efficient arrangement. But it seems that prevents setting the redirectUri on a per-request basis.

Although I suppose there are probably only a handful of entry points in an application in which case one could make a dynamic Map of Clients for each entry point and then just dispose of them after some expiration. Most requests would re-use a Client so that's effectively just as efficient.

from duo_universal_java.

These are all totally feasible ideas. They're probably overly complicated for what we want to include in our very simple demo application, but in a real application you could definitely use some of these practices. The filter flow definitely would let you combine steps as you noted above.

I believe the client should be flexible enough to accomplish this, but if you find it lacking, let us know if there's a potential change that would make it more useful.

Since you got things working, I'll close this issue, but keep us posted if you have further problems. Thanks for using Duo!

from duo_universal_java.