peppelinux commented 3 years ago

oidcop Satosa Frontend

Tested with JWTConnect-Python-OidcRP.
Mongodb storage for client and session, additional storage engines may be implemented in the future.
Demo project

satosa_oidcop

endpoints

[x] provider discovery
[x] jwks uri
[x] authorization
[x] token
[x] userinfo
[x] registration
[x] registration_read endpoint
[x] introspection endpoint (https://github.com/IdentityPython/SATOSA/pull/378/commits/473310fb5968561f962bf6bcc6b6eacbf78f0b3e)
[ ] token exchange

todo

[x] unit tests
[x] pytest mongo mock
[x] test response_type = "code id_token token" (https://github.com/IdentityPython/SATOSA/pull/378/commits/a61dc99503bcb9d4982b77a6ddcf0c41b6732915)
[x] auto prune expired sessions with mongodb index (https://github.com/IdentityPython/SATOSA/pull/378/commits/137993f77bfb05b44f25ba6df3784e8fb86a31ce, mongo index)
[x] token refresh (https://github.com/IdentityPython/SATOSA/pull/378/commits/59c0a53fa73e70551d76c5355c051a7389ab99fd)
[ ] ~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.
[ ] DPoP support
[ ] general frontend configuration yml file review and refactor (https://github.com/IdentityPython/SATOSA/pull/378/commits/b7668f741b667e0ee8242a234c0380191f50a7df)
[ ] satosa best practice compliances
[ ] Refactor scopes/claims configuration following this

peppelinux commented 3 years ago

Here a brief description about the main characteristics of this implementation.

Design principle 1

Anyone 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 config.op.server_info have a standard SATOSA configuration with the only addition of the following customizations, needed in SATOSA for interoperational needs. These are:

autentication

    authentication:
      user:
        acr: urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPassword
        class: satosa.frontends.oidcop.user_authn.SatosaAuthnMethod

userinfo

userinfo:
  class: satosa.frontends.oidcop.user_info.SatosaOidcUserInfo

authentication inherits oidcop.user_authn.user.UserAuthnMethod and overloads two methods involved in user authentication and verification. These tasks are handled by SATOSA in its authentication backends.

userinfo inherits oidcop.user_info.UserInfo and proposes a way to store the claims of the users when they comes from the backend. The claims are stored in the session database (actually mongodb) and then they will be fetched during userinfo endpoint (and also token endpoint, for having them optionally in id_token claims).

Weakness of SatosaOidcUserInfo

It stores the claims of the user in the db
It loads some temporary data and flush them before returning the userinfo response, here

unhandled features

oidcop SSO and cookies were not have been implemented because SATOSA doesn't support logout, because of this they are quite useless at this moment.
~dynamic client registration and registration_api are not needed in my deployments but we can have them in a future roadmap~ (implemented)
DPoP, introspection and exchage SHOULD be implemented

Client and Session Storage

MongoDB is the storage, here some brief descriptions for a demo setup. The interface to SATOSA oidcop storage is satosa.frontends.oidcop.storage.base.SatosaOidcStorage and it have three methods:

get_client_by_id(self, client_id:str, expired:bool = True)
store_session_to_db(self, session_manager, **kwargs)
load_session_from_db(self, req_args, http_headers, session_manager, **kwargs)

satosa.frontends.oidcop.storage.mongo.Mongodb overloads them to have I/O operations on mongodb.

peppelinux commented 3 years ago

Storage design principles

At this time the storage logic is based on oidcop session_manager load/dump/flush methods. Each time a request is handled by an endpoint the oidcop session manager loads the definition from the storage, only which one are strictly related to the request will be loaded in the in memory storage of oidcop.

~Due to this fact, this implementation MUST be improved to properly detect the request to handle the introspection/exchange/registration endpoints.~

Weakness of the storage model

it'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. Each workers loads and updates the data of a specific session by their own.

This approach CAN'T be deployed in a asyncio-based approach, but can't see any weakness with standalone workers.

Use case

In 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;;clientid because the dumped session has all in it, another session will not touch the previous one, because:

sessions are always flushed before and after operations
sessions are always dumped entirely in a separate instance

This implementation definitely:

removed any relational constraints between many sessions produced by the same client;;user (oidcop subordinates)
prevents that a newly created Grant could add a subordinate to any other session and vice versa

To get instead relations between many sessions there will be the need to query the storage engine, with its native query lookup method.

peppelinux commented 2 years ago

@c00kiemon5ter moved to https://github.com/UniversitaDellaCalabria/SATOSA-oidcop