Hey!
I've been testing the By Url functionality in ZDEW and it's been great!
I noticed a few things which I wanted to clarify if they should be happening or not.
I'm assuming that after authenticating with my external id provider, Ziti refreshes the token in the background, am I correct here?
I wanted to test this so I went to the keycloak admin console and signed out the active openziti-client session. When Ziti tried to refresh the token it wasn't able to and it displayed this in ZDEW:
Since it can't refresh a session that has been terminated, should it recover by getting a new session?
I was still able to access the services for that identity and was wondering is that supposed to be possible?
Other thing I noticed is that when clicking the authorize IdP it failed to properly launch the authentication flow to Keycloak. Instead I got this:
ZDEW version: 2.7.3.1
Thanks in advance!
Hi @montwepa, this bug is something we've been working on fixing for a couple of weeks. There have been a couple of other fixes that were needed first. It seems like this is most often a display issue where the tunneler confuses the UI. While you still have access to the services, the UI doesn't think you do and when you try to authorize you get the failure screen shot you show. So know that it's a bug we're working on fixing. The quick workaround for now is to just toggle that enabled button off/on and then you should be able to authorize properly using the UI.
This is a qualified "probably". It really just comes down to how you configure your idp. If you allowed for refresh tokens, then the tunneler will authorize, obtain id, access and refresh tokens and then use that refresh token accordingly to obtain a new token. If that process fails for some reason, you should get the 'authorize IdP' UI you see. The bug right now seems to be a timing issue around that process.
Hopefully that answers all the questions you have here? I think it does but if I missed something or wasn't clear enough, just lemme know. Cheers
Hi @TheLumberjack, glad to hear you are aware of this and working on it 
You answered me well, but just so I am sure - once the bug is fixed, what should the expected flow look like?
For example, let's say I configure Keycloak to:
- Deny refresh tokens
- Set tokens with 1-hour lifetime
In this scenario, would users lose access to services every hour until they complete the "Authorize IdP" flow again? Or would the services remain accessible while only the UI prompts for re-authorization?
Thanks for the clarification!
In this scenario, would users lose access to services every hour until they complete the "Authorize IdP" flow again?
That's an entirely reasonable expectation and i would probably have that same expectation. I wasn't deeply involved in the implementation and the feature is still relatively new to OpenZiti so I'm not 100 percent sure what will actually happen. What i think will happen is the user will continue to have access to services until they are offline long enough to miss refreshing the session with the controller.
My understanding of the process right now (and i might be wrong) is that a client authorizes with the idp to obtain tokens from the idp and then exchanges the idp token for ones from OpenZiti. Then when refreshing a session from OpenZiti the client uses the OpenZiti tokens. If you're offline during the OpenZiti session refresh, when the client comes back online it will try to auth with the controller using a token that has expired, fail, then try the idp token to get a new OpenZiti token. At that point if the refresh token is expired, the UI should get the familiar idp authorize button and the user will auth.
What your describing is perhaps more like an OpenZiti posture check for idp. Similar to this one Feature Request - Posture check associated to the claims in a token from an IdP. · Issue #3288 · openziti/ziti · GitHub
I'll point @andrew.martinez here to see if I'm correct or perhaps correct my understanding
1 Like
