11:47 a.m.
Since I've been able to answer my own question about manual client
registration (w/o MongoDB) in another thread (now resolved)
https://lists.sunet.se/pipermail/satosa-users/2020-March/000120.html
I'm starting a new thread about the latter (unrelated) issue:
Starting at the oidc-enabled app I'm sent to satosa with an auth
request, the client is now known/found (client_db details shared at
the above URL), the saml backend is involked, SAML WebSSO happens,
attributes are mapped and I am back "Routing to frontend: oidc".
Then satosa raises an InvalidAuthorizationCode exception:
[pyop.authz_state.create_authorization_code] creating authz code for scope=openid email
profile
[pyop.authz_state.create_authorization_code] new authz_code=eff...cd79 to
client_id=someClientId for sub=someid at example.org valid_until=1585612419
...
[satosa.proxy_server.unpack_request] read request data: {'grant_type':
'authorization_code', 'code': 'eff...cd79',
'redirect_uri': 'https://some.example.org/auth/callback'}
...
[pyop.client_authentication.verify_client_authentication] client authentication in
Authorization header Basic base64-encoded-client_id_colon_client_secret
[satosa.frontends.openid_connect.token_endpoint] invalid request: eff...cd79 unknown
Traceback (most recent call last):
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/frontends/openid_connect.py",
line 363, in token_endpoint
response = self.provider.handle_token_request(urlencode(context.request), headers)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py",
line 324, in handle_token_request
return self._do_code_exchange(token_request, extra_id_token_claims)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py",
line 352, in _do_code_exchange
authentication_request =
self.authz_state.get_authorization_request_for_code(token_request['code'])
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/authz_state.py", line
320, in get_authorization_request_for_code
raise InvalidAuthorizationCode('{} unknown'.format(authorization_code))
pyop.exceptions.InvalidAuthorizationCode: eff...cd79 unknown
So the authz code created above (first line) is now unkown (last line).
Why would that happen and what can I do to avoid it?
On the RP side (seemingly using
https://www.npmjs.com/package/openid-client) I currently only see the
same thing as RP is merely relaying the OP error, it seems. And this
being an OP error I probably don't have to dig into the RP side to get
more/better logging:
OPError: invalid_grant (eff...cd79 unknown)
at processResponse
(/opt/edumeet/mm/server/node_modules/openid-client/lib/helpers/process_response.js:45:13)
at Client.grant
(/opt/edumeet/mm/server/node_modules/openid-client/lib/client.js:1235:26)
at process._tickCallback (internal/process/next_tick.js:68:7)
I'd appreciate suggestions on what I could have done wrong following
the satosa documentation where available, or how to further debug this
issue.
If other/more information (config details, logs, etc.) are needed or
my obscuring of details above is unclear I'm happy to provide those.
-peter
7:19 a.m.
Hi Peter,
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.
Can you also perhaps share you client config?
Niels
On 31-03-2020 13:47, Peter Schober wrote:
Since I've been able to answer my own question
about manual client
registration (w/o MongoDB) in another thread (now resolved)
https://lists.sunet.se/pipermail/satosa-users/2020-March/000120.html
I'm starting a new thread about the latter (unrelated) issue:
Starting at the oidc-enabled app I'm sent to satosa with an auth
request, the client is now known/found (client_db details shared at
the above URL), the saml backend is involked, SAML WebSSO happens,
attributes are mapped and I am back "Routing to frontend: oidc".
Then satosa raises an InvalidAuthorizationCode exception:
[pyop.authz_state.create_authorization_code] creating authz code for scope=openid email
profile
[pyop.authz_state.create_authorization_code] new authz_code=eff...cd79 to
client_id=someClientId for sub=someid at example.org valid_until=1585612419
...
[satosa.proxy_server.unpack_request] read request data: {'grant_type':
'authorization_code', 'code': 'eff...cd79',
'redirect_uri': 'https://some.example.org/auth/callback'}
...
[pyop.client_authentication.verify_client_authentication] client authentication in
Authorization header Basic
[satosa.frontends.openid_connect.token_endpoint] invalid request: eff...cd79 unknown
Traceback (most recent call last):
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/satosa/frontends/openid_connect.py",
line 363, in token_endpoint
response = self.provider.handle_token_request(urlencode(context.request), headers)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py",
line 324, in handle_token_request
return self._do_code_exchange(token_request, extra_id_token_claims)
File "/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/provider.py",
line 352, in _do_code_exchange
authentication_request =
self.authz_state.get_authorization_request_for_code(token_request['code'])
File
"/usr/local/venv/SATOSA/lib/python3.7/site-packages/pyop/authz_state.py", line
320, in get_authorization_request_for_code
raise InvalidAuthorizationCode('{} unknown'.format(authorization_code))
pyop.exceptions.InvalidAuthorizationCode: eff...cd79 unknown
So the authz code created above (first line) is now unkown (last line).
Why would that happen and what can I do to avoid it?
On the RP side (seemingly using
https://www.npmjs.com/package/openid-client) I currently only see the
same thing as RP is merely relaying the OP error, it seems. And this
being an OP error I probably don't have to dig into the RP side to get
more/better logging:
OPError: invalid_grant (eff...cd79 unknown)
at processResponse
(/opt/edumeet/mm/server/node_modules/openid-client/lib/helpers/process_response.js:45:13)
at Client.grant
(/opt/edumeet/mm/server/node_modules/openid-client/lib/client.js:1235:26)
at process._tickCallback (internal/process/next_tick.js:68:7)
I'd appreciate suggestions on what I could have done wrong following
the satosa documentation where available, or how to further debug this
issue.
If other/more information (config details, logs, etc.) are needed or
my obscuring of details above is unclear I'm happy to provide those.
-peter
_______________________________________________
satosa-users mailing list
satosa-users at lists.sunet.se
https://lists.sunet.se/listinfo/satosa-users
--
Niels van Dijk Technical Product Manager Trust & Security
Mob: +31 651347657 | Skype: cdr-80 | PGP Key ID: 0xDE7BB2F5
SURFnet BV | PO.Box 19035 | NL-3501 DA Utrecht | The Netherlands
www.surfnet.nl www.openconext.org
6: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
1506
days inactive
1509
days old
2 comments
2 participants
participants (2)
-
niels.vandijk＠surfnet.nl -
peter.schober＠univie.ac.at