Returning to correct room after authentication #105
Comments
|
|
|
Thanks for a very quick answer! I still don't follow though, what do you mean by "the URL of this project"? Is that (auth.meet.example.com in your example) supposed to point directly to jitsi-openid (the site answering on port 3000)? |
|
yes, of course with a reverse proxy -> in the end the port should be 443 |
|
Ah, then things are getting clearer! I think this could be explained a bit clearer in the readme... Just so that I'm clear now:
I'm still not really following how Jitsi is supposed to know which room to put the user in when it's returned from the auth flow? |
|
the redirect url also has to be |
|
The redirect uri should be everything from jitsi opened (every path) |
|
Ok! With your help I'm slowly getting there :-) I am now (after enabling the implicit flow and adding scopes named "profil" and "email") getting my idp to accept the incoming authorization request and return a callback call to jitsi-openid. However, jitsi-openid doesn't seem to like the answer. After logging in, the user is now redirected to https://my_jitsi_openid_url/callback#state=eyJyZXR1cm5UbyI6Ii8ifQ&token_type=Bearer which seems correct to me. But jitsi-openid just says "Bad Request" and in the Docker log I get the following:
Any idea what's happening? |
|
Sorry for the things with the scopes. I only teste it with keycloak and these are there allowed by default. Jitsi openid generates a state witch is then sound be added to the redirect uri by the idp. https://stackoverflow.com/a/26132537 |
|
Yes, but if you look at the url it's redirecting back to, there is a state there, that's why I don't really understand the error... |
|
Hi again. I don't know, this is maybe starting to be a question worth asking at the express-openid-connect project instead? |
|
The fragment is because of the implicit flow -> the fragment isn't send to the server and implicit flow means that the response is handled client side, witch wouldn't work for this use case. Why do you need the implicit flow? |
|
Hmmm... No, I don't actually need the implicit flow, I just got the impression that's what is used. Now I realize though that it actually says response_type=id_token. Seems the problem is that my idp for some strange reason thinks it IS implicit flow. I guess I'll have to check with the support for our idp software. But shouldn't the state be sent as fragment also when response_type is id_token? |
|
No because it is interpreter by the backend and fragents are not passed to the backend |
|
Good point. According to the specs it should be in a fragment though and in my idp it's not configurable. I don't know how it's handled in other systems, is it the frontend page's work to send it on to the backend in some way? The only solution I can see right now is to build my own intermediate callback page that uses JS to convert the url (replacing the # with ?) and then passing it on to the "real" callback. Seems like a workaround more than a solution though :-/ |
|
Ok, after some more reading I think I found the culprit. jitsi-openid sends response_mode=form_post which means the idp should post the result as a form post. My idp totally seems to ignore response_mode so I guess the problem lies there :-/ |
|
Ok, I found an option in the underlying liberty to change the response mode. Unfortunately, I currently don't have direct access to a jitsi using this script. I asked one of my friends, idk when he will respond. I added a new env variable: I pushed it in master, the docker image is available over the tag |
|
Thanks, that's appreciated! I don't think it will help in my case though since it seems my idp actually completely is ignoring the response_mode. So my current theory is the problem was at that side all the time, I'm in contact with the support to get a solution. |
|
Ohh, I thought it refused to accept a response mode of form post. I just tested it and it didn't work, the library only accepts form_post |
|
Hi, it's me again. I've come a little further now, but still not really there... First my idp redirected to https://redacted_name.se/callback#state=eyJyZXR1cm5UbyI6Ii8ifQ&token_type=Bearer and then I got this in my log:
Now I have fixed a rewriting of the url from # to ? so the idp instead redirects to https://redacted_name.se/callback?state=eyJyZXR1cm5UbyI6Ii8ifQ&token_type=Bearer so the state reaches jitsi-openid, but now instead it says this in the log:
So obviously something changed, but it still doesn't like it. Any idea what goes wrong now? edit: Actually, after reading a bit (here) I think the problem might be a cookie getting lost somewhere down the road. I'll continue investigating... |
|
Ok. Now I'm stuck on the last redirect, hope you can help me see what's going wrong... After logging in I'm now stuck in a never ending loop:
While this loop is happening I can actually see my camera picture in the browser so I think I'm logged into the room and the redirect loop seems to happen in the background. After a few seconds though I'm thrown to a "too many redirects" error page instead. Any idea what could cause this behaviour? |
|
If you can see your camera, that must mean you are going over jitsi direct? |
|
I think the openid connect implementation that I use only supports id_token, maybe I should switch the implementation. I am going to rewrite this in rust and use this implementation, it seems that it supports that code authentication that we need: https://github.com/ramosbugs/oauth2-rs (then it is only oauth2 and not opened connect -> the is no autodiscovery)
|
|
Could you maybe provide me with the name of your IDP, so that I could test if it works, or is it some kind of paid enterprise software? Currently, I (can) only test with keycloak. |
|
Yep, it's a paid enterprise solution (this one) so I don't think there's any easy way for you to test it. I could give you an url and a test account to the test environment so you could see the behaviour yourself but I guess it wouldn't be meaningfull without shell access to the server and that would be harder to fix. But it should work the way I have set it up now right? So that when the callback endpoint gets a request with a state and the correct cookies should make jitsi-openid construct a correct jwt and send it on to Jitsi? I don't really see why it would then redirect back to it's own room endpoint like it does now. Could it make any difference that the state now is sent as an url query even though it should be as form post? Also, is there any way to increase the debugging to see more of what is happening? |
|
I think the express implementation only supports id tokens, the rust version would use the state stuff. Yes now it should work. The redirect currently happens because express could'nd find The Id toke n. |
|
Ok, but where does it look for the id token? If I understand things correctly what is supposed to happen now is that it calls the token endpoint on my idp to get the id token, I'm not really sure if that is happening? |
|
Yes, but the express implementation directly asks for an id token in the auth URL as a response. Your idp is ignoring this/not supporting this and is sending a code. |
|
I did a rewrite witch uses a different implementation with way more capabilities. Could you may try it out. The docker image uses the tag |
|
Great news! I'm strongly suspecting my idp software is the big problem for me (still waiting for their support to confirm my problems) but everything I can do to work around it is appreciated! This new version does not seem to like my ISSUER_BASE_URL though, it's quite long. When starting the container I get this:
The json with my openid-configuration is reachable at https://idp.my_domain.se/https/api/rest/v3.0/oauth/qG4ZETXFGdc4Nj33ACW6/.well-known/openid-configuration. |
|
I know... This implementation (an maybe even the openid connect spec is expecting the issuer URL to be the same as provided as the environment variable for I already created an issue, while I encountered the same issue. A temporary workaround would be to fork the implementation and disable this check. Is your openid connect discovery also available at |
|
Ok, then I am going to create a temporally fork of the underlying implementation until they responded to my issue. |
|
Cloud you try it again, I just verified that it worked for my setup. (described here ramosbugs/openidconnect-rs#75) |
|
Yep, now it starts as intented! And now I get a very clear error message about missing id token. You have clearly convinced me that the problem lies within my idp, either a bug or a misconfiguration. I'll report back when I have more information! |
|
The problem with that is that the id token is not mandatory according to the spec. You may have an option to enable it on the admin interface. I also could implement an additional call to the user info endpoint. |
|
Could you try it again, I added user info and verified that it is working for keylcoak. (If I force disable the id token.) |
|
Wow!!! I think that actually worked! I'm not really sure what you changed, but now it I was sent on to Jitsi with a jwt including my username, just like magic! |
|
I think I have another (maybe last) question: Is there any way to get it to send more user information in the jwt? Currently it sends this user info:
(where damal08 is my username) |
|
I assume that the basic authentication process is not working. 🎉 Theraticly this information is being passed: https://github.com/MarcelCoding/jitsi-openid/blob/main/src/main.rs#L298-L307 At least for keycloak it is working. It could be that either your IDP doesn't provide this information or has different properties' names. I could implement it for you if you provide me with an example of your user info endpoint response. (or is there public documentation, I could find any) |
|
Ah! Well, with that info it was a piece of cake, I only needed to include attributes named "name" and "email" in the Oauth2 info from my idp, so now I get my name in the meeting! Now if I could just tell Jitsi to prohibit the user from changing that name before going into the room... |
|
Yep, I'm already on it :-D Thanks a lot for your hard work on this, I realize you've gon lengths to help me. Can I do anything to compansate you? |
|
You really don't have to do anything, it's currently just a hobby. I am just a student :D I am going to leave this issue open until ramosbugs/openidconnect-rs#75 is finished. After that, I am also going to create a new release. |
|
Hi again. I've got a new problem, but I thought I'd handle it here as well, since I'm using the edge version discussed above in this issue. My problem now is the expire date of the jwt. I'm not really sure how it's calculated, but when I'm trying now I get jwt's which expired almost a week ago which makes Jitsi not accept them. When I try in an incognito tab everything works fine so it seems it has something with my browsers session to do, could it be that the exp date was set when I tried around with this last week and then isn't updated correctly? edit: After some more testing, it seems this only happen if I in the list of meetings click a meeting that was created last week. Joining meetings created today works fine. Could it be that the exp date is based on when the meeting was created? edit 2: After even more digging I realize that the meetings in that list is saved as cookies in my browser and that the entire URL including the jwt is saved there, so it never asks jitsi-openid at all when clicking those links. So this is clearly not a problem with jitsi-openid but rather in Jitsi itself, someone obviously did a bit of a think tank here. |
|
That's interesting because anytime I wasn't logged in into jitsi (expired or no jwt) there came a popup with a button "I am the host", where I got redirected to the login page. |
|
That's weird. I guess there's som other setting affecting this? I think I will simply go around the problem by disabling the list completely (RECENT_LIST_ENABLED=false), I have no real need for it anyway. Discussed it here. |
|
Hi, I am again. I just updated the description regarding jwts. I also implemented some logic for someone else. It should affect you, (I tested everything using keycloak) I just want to be sure that it also works for your IDP. (#122) |
|
Hi. I tried now and I can't get it to work. Is this new option supposed to be optional? If I don't include the new option in my yml file the container doesn't start at all, it says "missing field
I also tried configuring my idp to send a static dummy value for acr, but I get the same error. (edit: I realize now though that this might not be sent in the id token so I guess it makes no difference. Seems simply my idp solution doesn't have support for acr so it would need to be optional) |
|
Sorry, my bad - I forgot to make the "acr_values" optional - If you specify acr_values an id token is required to validate them, if you don't specify any, the id token is optional. It should be working now - the build maybe take some time 1ef7808 |
|
Yep, works like a charm now! Since my idp doesn't seem to have support for acr I can not test that particular function, but at least it works like before without it :-) |
|
Unless you want to force users to use a specific authentication class - (force password, security key, ...) this isn't something that you want to use. |
|
Yep. And I can simply choose which authentication methods in the idp is available for this oidc client, so there's no need for passing that information in the token. What do you say, should we close this issue up? All my problems are solved now! Or should you make a release first? |
|
And this is also fixed for you, that means I can switch back to the upstream version and do not need to use my fork anymore? |
|
You're talking about the openidconnect-rs issuerurl issue now, right? Yes, I think that should be safe. |
|
Ok, I am going to create a release. |
do you mean the redirect uir should be the same as the TOKEN_AUTH_URL? |
can you please give an example how to set redirect uris in authelia conifiguraiton file? |
|
https://keycloak.marcel.hel1.not4y.net/realms/main/.well-known/openid-configuration You have something like this for your provider. The issuer url is the part of the url up to |
Hi.
After hours and hours of struggling (starting to feel like this guy) I think I almost have got oidc authentication working with Jitsi, but I'm stuck and hope to get some help here. I have got this far:
However, when I'm sent back I don't end up in the room I tried to enter but back on the main page. How is the flow supposed to work? Shouldn't jitsi after successful login do the redirection into the room?
Also I don't understand the TOKEN_AUTH_URL parameter. To get it working this far I have set it to the following:
https://idp.redacted/https/api/rest/v3.0/oauth/authorize?client_id=qG4ZETXFGdc4Nj33ACW6&response_type=code&redirect_uri=https%3A%2F%2Fvideo.redacted&scope=openid
...but from the example on the readme I guess I should put the room somewhere here and I don't understand where and how. Is the auth server supposed to do something with the room name and return it to Jitsi so that it knows which room to enter?
The text was updated successfully, but these errors were encountered: