Package: satosa-oidcop
SATOSA oidcop frontendSATOSA Frontend based onidpyoidc by Identity Python(previouslyidentity python oidcop).FeaturesEndpoints:provider discoveryjwks uriauthorizationtokenuserinforegistrationregistration_read endpointintrospection endpointtoken exchangeRequirementssatosamongodb, seeSatosa-Saml2Spid mongo example.Setuppipinstallsatosa_oidcopConfigurationAnyone can migrate its oidcop configuration, from flask_op or django-oidc-op
or whatever, in SATOSA and without any particular efforts. Looking at theexample configurationwe see thatconfig.op.server_infohave a standard SATOSA configuration with the only
addition of the following customizations, needed in SATOSA for interoperational
needs. These are:autenticationauthentication:user:acr:urn:oasis:names:tc:SAML:2.0:ac:classes:InternetProtocolPasswordclass:satosa.frontends.oidcop.user_authn.SatosaAuthnMethoduserinfouserinfo:class:satosa.frontends.oidcop.user_info.SatosaOidcUserInfoauthenticationinheritsoidcop.user_authn.user.UserAuthnMethodand overloads two methods involved in user authentication and verification.
These tasks are handled by SATOSA in its authentication backends.userinfoinheritsoidcop.user_info.UserInfoand 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).SSO and cookiesoidcop SSO and cookies were not have been implemented because SATOSA does not
support logout, because of this they are quite useless at this moment.Client and Session StorageMongoDB is the storage,heresome brief descriptions for a demo setup. The interface to SATOSA oidcop
storage issatosa.frontends.oidcop.storage.base.SatosaOidcStorageand it has
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.Mongodboverloads them to have I/O
operations on mongodb.Subject typeThe client configuration can also include thesubject_typekey,
with permitted values beingpublicandpairwise. If absent, the default is
to choosepublic. This has been driven by backwards compatibility
with existing behaviour: oidcop (session_manager.create_session)
defaults topublic.For user privacy, we strongly recommend selectingpairwisefor
new deployments, unlesspublicis absolutely needed
(for linking users across related but distinct services).DemoSatosa-Saml2Spidis a custom
Satosa configuration to deal with many SAML2 and OIDC Relying parties
and many eduGain and SPID Identity Provider.ContributionsFeel free to open issues and pull requests, we build communities!Developer notesStorage designAt 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 loadedin the in memory storage of oidcop.Roadmapunit testspytest mongo mocktest response_type = "code id_token token" (hybrid flow)auto prune expired sessions with mongodb index
(auto prune,mongo index)token refreshDPoP supportTestsBefore you run the tests mind that you've to start a local mongod instance,
e.g. with:sudodockerrun\--rm\-eALLOW_EMPTY_PASSWORD=yes\-eMONGODB_ENABLE_JOURNAL=false\-p27017:27017\--namemongodb\bitnami/mongodb:latestIf you like you can use mongo-express as a management UI over the local mongo instance:sudodockerrun\-eME_CONFIG_MONGODB_SERVER=$MONGOHOST-OR-DOCKER-BRIDGE-LIKE-172.17.0.1\-p8081:8081\mongo-expressThen run the tests:pipinstallpytestpytest-cov
pytest--cov=satosa_oidcop-v--cov-reportterm--cov-fail-under=95tests/AuthorsGiuseppe De Marco @ Università della CalabriaCreditsRoland HedbergAndrea Ranaldi @ ISPRA AmbientePavel Břoušek @ CESNETIdentity Python Community