On 2017-06-13 08:42, Ioannis Kakavas wrote: Yeah absolutely true. I will be happy to review! Right - I actually think a microservice is better for this reason. I'm also wondering if the attributemapper itself could not be broken out as a microservice? That would seem like cleaner architecture Cheers Leif

Hi all and thanks for the responses, On 13 June 2017 at 16:24, Scott Koranda <skoranda at gmail.com> wrote: We will go forward and implement a new microservice (probably call it attribute-processor or something alike) to enable us to process attribute values before mapping them. Regarding breaking out attribute-mapper as a microservice, I had thought about it before sending the above proposal, but I feel this path leads to major changes in SATOSA's architecture. I explain my thoughts below. The attribute-mapper module is the core of SATOSA; it is the main service SATOSA offers and the point that defines the internal representation of the data and everything else is built around it. [SP(external)] <protocol-x> [IDPsatosa <> attribute-mapper:internal-data <i> microservices <i> internal-data:attribute-mapper SPsatosa] <protocol-y> [IDP(external)] By changing the role of the attribute-mapper and moving it out as a microservice what we come to is: [SP(external)] <protocol-x> [IDPsatosa <internal-data> microservices <internal-data> SPsatosa] <protocol-y> [IDP(external)] This leaves a question mark on how the internal data are generated, as attribute-mapper has been moved into microservices and is now optional. If we break out the main service that SATOSA offers then the only difference that core has compared to generalised web frameworks is its offering of an IDP and SP component. The roles of the IDPsatosa and the SPsatosa components are to *handle* requests and generate responses. The role of the microservices is to *handle* the transition from protocol-x to protocol-y. Then why would we not abstract the IDP and SP components as microservices too and generalise their usage as request and response handlers: [SP(external)] <x> [request-handlers <context> response-handlers] <protocol-y> [IDP(external)] This leads to the classic middleware architecture where defined components handle a request and then produce a response. An ordered list of handlers is set and each handler is called until no handlers are left to handle the request, then the order is reversed and each handler is called until the response is formed. This results in clear separation of the request handlers, the internal data generation and state transitions, and the response generated as a reaction to the formed state from the request handlers. Separation of concern is the primary driving factor of this architecture. This results in making the IDPsatosa and SPsatosa components as microservices -thus making them replaceable- and defines a common interface between all microservices/handlers that will be called in order. Each handler handles the request and forms a response, and thus only two methods are needed to form the interface of the handlers: handle_request(ctx, req) and handle_response(ctx, req, res) - both act on the context/ctx object. The internal-data is represented in the context object, shared and passed around the handlers, and it is the same object where state is kept during the handling of the request and the generation of the response. The whole project could then be based on a generic web framework like flask, and each microservice would be a middleware/blueprint. IMO, this is the generic architecture that any flexible and extendable network application should follow. However, SATOSA is not currently following this model, and thus will need a big refactor to fit the above architecture. Of course one could go only half way, and move only the attribute-mapper module out as a microservice, but I do not see any immediate benefits by doing this. Kind regards, -- Ivan Kanakarakis

Hi On 14-06-17 09:19, Leif Johansson wrote: I would prefer not do that latter, nor move the attribute mapper of satosa core into microservices. We should keep a strict separation of responsibilities, which are: 1) handle incoming protocol X and map to internal state (Satosa core) 2) Do some magic on internal state if needed (micro service) 3) pick up internals state and represent in protocol Y (Satosa core) I do think therefor we need 2 mappers in the core, and in this specific case a 3th for the magic you need: <protocol-x> -> IDPsatosa -> mapper to internal state Result: <internal-data> <do your micro service magic on internal data, for example w/ a custom mapper> Result: <modified-internal-data> <internal-data> -> mapper from internal state -> SPsatosa -> <protocol-y> Both mappers from and to internal state are core to SaTosa and should I think *not* be directly touched by any micro servcies as that will break the ability to map from and to that data from various protocols in a generic way. They should also themselves not be microservcies as these are core to the capabilities of SaToSa. We do not want a situation where the protocol handling code needs to know about what internal state is going to be represented, as that will result in the need for updating *all* protocol handlers if a new protocol or microservice gets added. If you have additional requirements beyond mapping from protocol to internal state, that is up to your microservice. Microservcies should only ever touch an existing internal state. Cheers, Niels -- 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