-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: idpy oidcop frontend #378
Conversation
self.config["INTERNAL_ATTRIBUTES"]["user_id_from_attrs"] | ||
] | ||
internal_response.subject_id = "".join(subject_id) | ||
except KeyError as err: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise if a misconfiguration would happen SATOSA returns a KeyError exception from which it is difficult to know the cause from the logs.
This littl change makes satosa just more eloquent
67fbe8b
to
808ab76
Compare
Endpoint context
Here a brief description about the main characteristics of this implementation. Design principle 1Anyone can migrate its oidcop configuration, from flask_op or django-oidc-op or whatever, in SATOSA and without any particular efforts. Looking at the example configuration we see that
authentication inherits userinfo inherits Weakness of SatosaOidcUserInfo
unhandled features
Client and Session StorageMongoDB is the storage, here some brief descriptions for a demo setup. The interface to SATOSA oidcop storage is
|
Storage design principlesAt this time the storage logic is based on oidcop session_manager load/dump/flush methods.
Weakness of the storage modelit's transactional because it loads data from mongo to oidcop's in_memory engine before handling a request and dump the session data to mongo before flushing the inmem storage and doing the response. Each workers does its own. Workers can't grows data in concurrency between many concurrent requests, by design. This approach CAN'T be deployed in a asyncio-based approach, but can't see any weakness with standalone workers. Use caseIn the case we have 2 threads that have 2 different client sessions for the same key (user_id;;client_id). The doubt is that in this draft implementation one of them will write its changes to the db first and the other will overwrite it. Differently, in this implementation we have this behaviour: The same client, with different browser/device, produce different sessions. We do not have a relation to any other_user_id;;client_id_ because the dumped session has all in it, another session will not touch the previous one, because:
This implementation definitely:
To get instead relations between many sessions there will be the need to query the storage engine, with its native query lookup method. |
4b79c9c
to
59c0a53
Compare
0631ab0
to
9f4dd1a
Compare
1932f1b
to
8a7c3a3
Compare
31dbb43
to
5e45050
Compare
Added to the docs under external contributions: https://github.com/IdentityPython/SATOSA/blob/master/doc/README.md#external-contributions |
oidcop Satosa Frontend
endpoints
todo
rfc7523 - private_key_jwt test> a RP cannot reach the token endpoint if a user have not passed by authz endpoint before. private_key_jwt is a kind of authentication where the user interaction is not needed.