It has a number of endpoints - an authentication endpoint which can be mapped to a number of backends, but also a credential endpoint - to receive a credential. Initially this used a SATOSA backend connected to credential constructor. This could be considered "twisting the arm" of SATOSA , so instead there is now an API with a built-in credential constructor. Using the API you could also call a service outside SATOSA for an authenticated user with an id token. The credential issuer uses a trust pattern , which is the OpenID federation. Roland says he should probably make a OP frontend without the credential issuer stuff in it , but with the federation stuff in it. If you want to test, you need a number of entities : SATOSA, a wallet, and a federation with at least a trust anchor, wallet provider and a PID issuer (or some other credential issuer).

Roland is writing documentation from the digital wallet point of view. He wants to write it so that different audiences have their own targeted documentation; for example one section for IT architects or CIOs, another for deployers, another for developers who wish to extend the capabilities.

using https://openidconnect.net/ (test RP) and entering https://federation.scienceforum.sc/.well-known/openid-configuration for configuration, Matthew E receives "response type is not registered" errors.

client needs to define property which indicates what response types are allowed - by default it seems nothing is set. Matthew E also reported looking in database and saw no clients. May need to statically register a client - add an entry with Client id, client secret, client uri, and probably some structure that defines response types that client should be using. May need to get Giuseppe involved. There doesn't seem to be an example with the repo, and Matthew has looked through the code and can't seem to get it working correctly.

Roland says there are a number of classes you can use to implement the client database - it behaves like a dictionary. Roland could possibly provide a configuration file that provides hints how to implement. For instance, with the credential issuer frontend he didn't want to use mongoDb, so he used a simple persistent layer with a key-value database behind it - implemented where the file name is the attribute name, values are json within the file. He can provide an example of this. It would be easy to add a client in this case - just drop a new file in a specific directory, with a name that follows a convention and the content as json with the appropriate attributes (client id, client secret, redirect uri)

https://github.com/IdentityPython/SATOSA/pull/449 - current implementation only generates parts of the metadata - doesn't include all backends/frontends

https://github.com/IdentityPython/SATOSA/pull/450 - want to be able to set a preferred backend when generating metadata where multiple backends are available - problematic because routing is based on which endpoints the request comes through. In other words: One of the proxies SUNET is operating is set up such that there are multiple back ends and these are combined into one front end. There are multiple entity descriptors with no root. Also, the endpoints within the descriptors contain all the backends. It would be better to be able to select which endpoints of which back end are included in the metadata of the front end - a new option for a preferred backend. Changes current behavior of the proxy, but this problem needs to be addressed. Ivan needs to experiment and recreate this SUNET environment. This opens up a new concept for SATOSA - multi-tenancy. You would be able to specify which back ends can talk to which front ends - multiple groups - where policies are applied. This is a complex concept to implement.

https://github.com/IdentityPython/pysaml2/issues/944 - problems with Windows temporary files . There is a template that acts as a configuration as to how a request or response should be signed. A temporary file is written to (the temp file is an actual class within Python ecosystem / core Python libraries). Then xmlsec reads from this file to know what to do. Once a temporary file (that was created through the core Python library) is opened, Windows won't let other processes open the file and read it. Python should be addressing this rather than the project, but it's not happening. Ivan has a workaround that was never pushed - taking advantage of Python garbagecollector. Ivan will push and have the user test.

https://github.com/IdentityPython/pysaml2/issues/946 - race condition. Pysaml2 keeps state internally - in either an in-memory dictionary or a shelve file (Python-related) - a binary file that can be shared across processes. User is using the shelve module for state in a multi-processing service. Processes are trying to access the file at the same time. One process errors out and then the shelve module is corrupted. Solution would be to expose the state and manage it through a database or some other way. An interface is needed for this state, with proper adapters to be able to write or read from the storage back ends. Then using the shelve module or the in-memory dictionary (mySQL, Rides. etc) is a configurable option. This PR needs work to build that interface, carefully. Ivan will write a response to this, but there are other priorities right now.