8:45 a.m.
Niels,
Thanks for chiming in! This turned out to be a weird issue though I'm
still not sure whose issue it is. (My money is on eduMEET, though. ;))
* Niels van Dijk <niels.vandijk at surfnet.nl> [2020-04-01 09:19]:
Perhaps you could craft a curl statement that mimics
the behavior of
the RP. This way you can test you OP without also being dependent on
the RP implementation config.
Yeah, no, because I don't speak OIDC nor OAuth2 at this time.
Can you also perhaps share you client config?
How I configured the client (RP) in satosa: I have this in my cdb (I
added the redundant client_id after Mihály shared his config that
included it there, but it doesn't seem to matter if it's there or not):
{
"s6BhdRkqt3": {
"response_types": [
"code",
"id_token token"
],
"client_id": "s6BhdRkqt3",
"client_secret": "7Fjfp0ZBr1KtDRbnfVdmIw",
"redirect_uris": [
"https://rp.example.org/auth/callback"
]
}
}
(The client_id and _secret values are straight out of
https://tools.ietf.org/html/rfc6749#section-2.3.1
of course. :))
What I set as the RP's own client config) I shared here:
https://lists.sunet.se/pipermail/satosa-users/2020-March/000119.html
so in a config file like this:
https://github.com/havfo/multiparty-meeting/blob/master/server/config/confi…
I have the values corresponding to the above, all simple enough:
issuerURL : 'https://op.examlpe.org',
clientOptions :
{
client_id : 's6BhdRkqt3',
client_secret : '7Fjfp0ZBr1KtDRbnfVdmIw',
scope : 'openid email profile',
redirect_uri : 'https://rp.example.org/auth/callback'
}
*But* as I just described here
https://lists.edumeet.org/sympa/arc/community/2020-04/msg00017.html
it seems I merely was under the impression that my system integration
was generally wrong (because of the error I posted about on this list
earlier) -- but when repeatedly trying to log in to the RP (sometimes
removing all state from the webbrowser: fresh private browsing window,
or deleting cookies for the RP-side, sometimes keeping state and just
trying 15 or 20 or 30 times in a row) logging in to edumeet sometimes
*does* work and I get no pyop.exceptions.InvalidAuthorizationCode from
satosa and no "OPError: invalid_grant" from node openid-client.
I have satosa running on DEBUG all the time (as I'm the only user) so
I can try to put together a package of satosa logs, httpd access logs
and browser traces for working and on-non working cases, where they
only differ in how often I tried it in the browser (with *no*
server-side changes at all). I don't have any useful logging from the
RP side (edumeet), yet, though.
To me this all sounds very weird but I can probably demonstrate that
in a video or by making the server public for testing purposes (by
loading SAML IDP metadata from interested parties).
Aynway, so while this integration currently is completely unusable
(due to logins failing more often than working and then suddenly work
again) it seems there's no satosa misconfiguration at play.
So I'll shut up for now, until there's demand for more details.
-peter