Not able to get Webapp working fully with Konnectd over TCP
-
Hi @EtherMan,
this is the reason you get logged in without having a Token from Konnect:
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
define(‘SSLCERT_FILE’, ‘/certs/webapp/combo.pem’);
WebApp uses the ssl certificate to log into your server. The
When using a single-signoncomment only applies when authentication is enforced on the webserver level, e.g. when using mod_kerberos or shibboleth.You only need to remove the cert and should be fine afterwards.
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
konnectd-identifier-registration.yaml
This is technically not necessary, when <hidden> is also the domain that is set as the issuer in connect. apps running on the same domain are automatically trusted.
-
Eh? Now you’re making me REALLY confused here. So without that line… How does Webapp communicate with Server? It also doesn’t match description since description basically says it’s needed when using SSO (which I am since I’m using konnectd), and speak to the kopano-server using SSL, which I am.
Testing it with that line removed though, does work in so far as it still allows me to log in… Though I’m not sure why it would allow that. It has had absolutely zero effect on what happens after logging out though. It has made one change it seems though. I’m now getting an error in konnectd that “time=“2020-05-05T12:17:44Z” level=debug msg=“IdentifierIdentityManager: id_token_hint does not match request” error=“invalid origin: https://<webapp base domain url>””
-
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
It also doesn’t match description since description basically says it’s needed when using SSO (which I am since I’m using konnectd), and speak to the kopano-server using SSL,
the important part comes after the above two statements “and authenticate using an SSL certificate.” You don’t authenticate with an ssl certificate when doing an oidc login. you actually authenticate through oidc. And like I said before login with an ssl certificate is only needed when your webserver is your gatekeeper (e.g. when using kerberos or saml). Although I have not checked, I would be surprised if the documentation tells you something different.
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
https://<webapp base domain url>
So is
<webapp base domain url>the same domain that you have Konnect listening under? Is it the same domain that you have prevously masked with<hidden>? -
Err… The Webapp system is authing using SSL certs no? Every other component is after all. And I don’t get what you mean by webserver being the gatekeeper… Ofc it is? It’s the webserver serving the content so ofc it’s the gatekeeper? That would be the case regardless of who or what is lending you to the key.
And webapp base domain url and all <hidden> domains are the same domain, but not all the same subdomains. Konnect is on oidc.domain.tld while webapp is on webapp.domain.tld, server on kopano.domain.tld
-
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
The Webapp system is authing using SSL certs no?
No. The users authenticate through oidc. It is not WebApp that is authenticating itself to the server (which is what components such as dagent or search are doing).
Ok just pretend I did not say “domain”, but “fully qualified domain name”. You must use the precise domain and any subdomain or toplevel domain in the identifier registration.
-
Right, so fqdn. Then those are different… But so then, what is needed to be different? The issuer identifier in Server, is oidc.domain.tld. The issuer identifier in konnect is oidc.domain.tld, the issuer identifier in webapp is oidc.domain.tld, the konnectd-identifier-registration.yaml urls, are all webapp.domain.tld. Though technically, I’d prefer components not communicating in between them over those urls because then they go over the reverse proxy, so just more points of failures. Hence why they’re defined with just the internal hostnames of kopano-server in that case. The invalid origin line of the log from konnect though, does not even have the /webapp at the end though, but I’ve not specified any such url anywhere.
-
It needs to be a publicly reachable domain, because that is what users use to reach WebApp and make use of oidc.
-
Hmm… I tried adding another origin to the konnectd-identifier-registration.yaml without the /webapp at the end… And now it works to log out it seems. I got that file layout from the guides somewhere though which didn’t have any entry for without /webapp
So much confusing stuff in this. It’s still not auto creating stores for users though. So have to manually go into the server container and run kopano-cli commands, which randomly fail, and when they fail, I have to detach, delete and recreate the store because it creates them in a faulty state for whatever reason… It’s weird… But for now at least, it works.
And webapp and oidc are both publicly accessible domains. And server is also on a publicly accessible domain. Webapp and konnectd just isn’t speaking to server over that.
-
Hmm nope. No no no no… Very very wrong now. Two major errors. Logging in and out currently works (sort of). But first issue is that passwords are not verified… Like, at all. As long as username is provided, it logs you in as that user regardless of password provided. The second issue is that while it works in Brave, Chrome and Firefox, but Internet Explorer does not.
Navigation Event Separator DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337 identifier HTML1300: Navigation occurred. webapp DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337 identifier UserManager.ctor: monitorSession is configured, setting up session monitor WebStorageStateStore.get user:https://oidc.domain.tld:kopano-webapp OidcClient.clearStaleState WebStorageStateStore.getAllKeys WebStorageStateStore.get user:https://oidc.domain.tld:kopano-webapp UserManager._loadUser: no user storageString State.clearStaleState: got keys 90bfa86e086f45ab9622a73e06a8de4c,b5939eabb4524f6dbf5bc5b878a8eb22,3fe4607b89af4b4cb9b386c926f5624c,040c38c35ea84605b3497181cec670f8,ebfd152f0a8e43ac86ccf3a4364ebaf5 "State.clearStaleState: got keys" [ 0: "90bfa86e086f45ab9622a73e06a8de4c", 1: "b5939eabb4524f6dbf5bc5b878a8eb22", 2: "3fe4607b89af4b4cb9b386c926f5624c", 3: "040c38c35ea84605b3497181cec670f8", 4: "ebfd152f0a8e43ac86ccf3a4364ebaf5", length: 5 ] WebStorageStateStore.get 90bfa86e086f45ab9622a73e06a8de4c WebStorageStateStore.get b5939eabb4524f6dbf5bc5b878a8eb22 WebStorageStateStore.get 3fe4607b89af4b4cb9b386c926f5624c WebStorageStateStore.get 040c38c35ea84605b3497181cec670f8 WebStorageStateStore.get ebfd152f0a8e43ac86ccf3a4364ebaf5 State.clearStaleState: waiting on promise count: 5 UserManager._loadUser: no user storageString UserManager.getUser: user not found in storage State.fromStorageString State.clearStaleState: got item from key: 90bfa86e086f45ab9622a73e06a8de4c 1588690106 State.clearStaleState: removed item for key: 90bfa86e086f45ab9622a73e06a8de4c WebStorageStateStore.remove 90bfa86e086f45ab9622a73e06a8de4c State.fromStorageString State.clearStaleState: got item from key: b5939eabb4524f6dbf5bc5b878a8eb22 1588690944 State.fromStorageString State.clearStaleState: got item from key: 3fe4607b89af4b4cb9b386c926f5624c 1588690954 State.fromStorageString State.clearStaleState: got item from key: 040c38c35ea84605b3497181cec670f8 1588690997 State.fromStorageString State.clearStaleState: got item from key: ebfd152f0a8e43ac86ccf3a4364ebaf5 1588691007 UserManager.getUser: user not found in storage WebStorageStateStore.get user:https://oidc.domain.tld:kopano-webapp UserManager._loadUser: no user storageString UserManager._signinStart: got navigator window handle OidcClient.createSigninRequest MetadataService.getMetadataProperty for: authorization_endpoint MetadataService.getMetadata: getting metadata from https://oidc.domain.tld/.well-known/openid-configuration JsonService.getJson, url: https://oidc.domain.tld/.well-known/openid-configuration JsonService.getJson: HTTP response received, status 200 MetadataService.getMetadata: json received MetadataService.getMetadataProperty: metadata recieved OidcClient.createSigninRequest: Received authorization endpoint https://oidc.domain.tld/signin/v1/identifier/_/authorize SigninState.toStorageString WebStorageStateStore.set 8093038336874e04847b6bee5349a740 UserManager._signinStart: got signin request IFrameWindow.navigate: Using timeout of: 10000 SCRIPT1002: Syntax error webapp (22066,31) IFrameWindow.timeout IFrameWindow: cleanup Frame window timed out UserManager._signinStart: Error after preparing navigator, closing navigator window oidc signin silent failed Error: Frame window timed out "oidc signin silent failed" { [functions]: , __proto__: { }, description: "Frame window timed out", message: "Frame window timed out", name: "Error", stack: "Error: Frame window timed out at Anonymous function (https://webapp.domain.tld/webapp/:21341:17) at run (https://webapp.domain.tld/webapp/:13361:13) at Anonymous function (https://webapp.domain.tld/webapp/:13378:30) at flush (https://webapp.domain.tld/webapp/:9195:9)" } Navigation Event Separator oidc signin silent did not return a user UserManager._signinStart: got navigator window handle OidcClient.createSigninRequest MetadataService.getMetadataProperty for: authorization_endpoint MetadataService.getMetadata: Returning metadata from settings MetadataService.getMetadataProperty: metadata recieved OidcClient.createSigninRequest: Received authorization endpoint https://oidc.domain.tld/signin/v1/identifier/_/authorize SigninState.toStorageString WebStorageStateStore.set ba0f70623489445ba330a55be4c0b43e UserManager._signinStart: got signin request DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337 webapp HTML1300: Navigation occurred. authorize UserManager.signinRedirect: successful oidc signing redirect undefined DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337 webapp Kopano Identifier build version: 0.33.0 Kopano Kpop build version: 2.2.0 SCRIPT5009: 'Promise' is undefined main.23aaf6b8.chunk.js (1,384)The errors keep getting weirder and weirder @fbartels >_<
-
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
but Internet Explorer does not.
Who still wants to use Internet Explorer?
You have not specified it about but my bet would be that you also use an SSL client certificate in Konnect. In that case the described behaviour is expected (you have seen the exact same with WebApp if you remember).
You only need an SSL certificate for services that need to authenticate themselves. In Konnect the user provides the authentication.
-
Ok that did indeed solve that one. Though I don’t quite understand this… Because basically, this means Server is accepting and speaking with… Well, anything? As in, anyone could set up say a webapp server that serves from my server, even if they themselves don’t even have an account? I understand they wouldn’t have user access to actually log in without an account and such, but it seems a pretty big deal to me that just anyone is allowed to set up frontends nilly willy. Especially considering that’s essentially giving people permission to do mitm attacks against users, with a live system that for all intents and purposes does work. Different components should auth themselves, as themselves, and have user authentication done inside of that authentication :/
As for who wants to use IE. Well, my parents do for one. I’m not about to teach two 80+ year olds about the wonders of new browsers. You’re not going to tell me that konnectd doesn’t work for IE are you? Please don’t >_<
-
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
Because basically, this means Server is accepting and speaking with… Well, anything?
Yeah. Just like connecting with an imap server, a webserver. If you can reach it, you can authenticate, you can use it. If you don’t want other to connect to it, you need to close it to the external world.
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
You’re not going to tell me that konnectd doesn’t work for IE are you? Please don’t >_<
-
Oh yea, it’s Edge that is the normal browser in Windows these days. And that works. Will have to check if they perhaps use that these days or they really are still using IE. Same icon so what is IE to them, may actually be Edge. Though “WebApp is supported for all production versions of Firefox, Chrome, Internet Explorer, Edge and Safari” does indicate that IE should still be supported, since it still is being shipped and updated.
As for imap comparison. The difference there is that if I use an IMAP client, I authenticate to the server, as myself, for myself. If I set up a Webapp frontend, I’m letting other users authenticate as themselves, to another service. A service I don’t need any account to in order to set up Webapp for. As in, there is no “you can authenticate”, because without client certificates being used by webapp to auth itself, setting up webapp does NOT require you to authenticate yourself to kopano, it just requires that the user wanting to log in does. And closing it to the world isn’t an option, since ofc, I still need to have my own webapp.
-
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
Though “[…]” does indicate that IE should still be supported, since it still is being shipped and updated.
Have a look at the bottom note.
@EtherMan said in Not able to get Webapp working fully with Konnectd over TCP:
The difference there is that if I use an IMAP client, I authenticate to the server, as myself, for myself
Not quite. You can also install e.g. roundcube on a server and as long as the server is the php imap module you can use this roundcube to log into the imap server that the admin configured in its configuration file.
I don’t fully understand your argument. Additionally you could host your own webapp at a location where this port can be reached, it just does not need to be publicly reachable.
-
Right, and I understand. I’m just saying that what I quoted contradicts what the table and the bottom note says.
As for roundcube, that is just an IMAP client though, it’s just web hosted. It is my understanding that WebApp is quite a lot more than just a client.
-
No, I would say essentially WebApp is “just” a client as well. It may be a powerful client, but in the end it also just uses a defined api to talk to the server backend.
